"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> Before emitting a call instruction, i need to check for function
> attributes. Based on that i need to emit the corresponding call
> instruction. For that, before emitting the call instruction, i check
> for the attributes of the called function throu
On Friday 22 December 2006 03:03, Paul Brook wrote:
> On Friday 22 December 2006 00:58, Denis Vlasenko wrote:
> > On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote:
> > > There are a lot of 100.00% safe optimizations which gcc
> > > can do. Value range propagation for bitwise operations, for
Snapshot gcc-4.1-20061222 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20061222/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I've updated the document describing Memory SSA. The section on mixing
static and dynamic partitioning is still being implemented, so it's a
bit sparse on details and things will probably shift somewhat before I'm
done.
http://gcc.gnu.org/wiki/mem-ssa
Feedback welcome. Thanks.
On Fri, 2006-12-22 at 12:30 -0500, Robert Dewar wrote:
>
> > Maybe on x86, but on PPC, at least for the (current) Cell's PPU
> > misaligned accesses for most cases unaligned are optimal.
>
> is that true across cache boundaries?
For Cell, crossing the 32byte boundary causes the microcode to hap
Andrew Pinski wrote:
On Fri, 2006-12-22 at 17:08 +, Dave Korn wrote:
Misaligned accesses *kill* your performance!
Maybe on x86, but on PPC, at least for the (current) Cell's PPU
misaligned accesses for most cases unaligned are optimal.
is that true across cache boundaries?
Thanks,
Andr
Dave Korn wrote:
On 22 December 2006 00:59, Denis Vlasenko wrote:
Or this, absolutely typical C code. i386 arch can compare
16 bits at a time here (luckily, no alighment worries on this arch):
Whaddaya mean, no alignment worries? Misaligned accesses *kill* your
performance!
is it really
On Fri, 2006-12-22 at 17:08 +, Dave Korn wrote:
> Misaligned accesses *kill* your performance!
Maybe on x86, but on PPC, at least for the (current) Cell's PPU
misaligned accesses for most cases unaligned are optimal.
Thanks,
Andrew Pinski
On 22 December 2006 00:59, Denis Vlasenko wrote:
> Or this, absolutely typical C code. i386 arch can compare
> 16 bits at a time here (luckily, no alighment worries on this arch):
Whaddaya mean, no alignment worries? Misaligned accesses *kill* your
performance!
I know this doesn't affect c
Rajkishore Barik wrote:
Hi,
Thanks very much. I still have doubts on your suggestion:
AFAIK, the back-end pass consists of (in order) : reg move -> insn sched
-> reg class -> local alloc -> global alloc -> reload -> post-reload.
There are edges from reg move to reg class and reload back to gl
On 21 December 2006 21:54, Ayal Zaks wrote:
>> Something along these lines may be useful to do in the vectorizer when we
>> get code like this: > ((char)x) = ((char)( ((int)((char)x)) <<
>> ((int)c) ) )
>> and don't feel like doing all the unpacking of chars to ints and then
>> packing the i
Jeffrey Law wrote on 12/22/06 01:09:
On Thu, 2006-12-21 at 14:05 -0500, Diego Novillo wrote:
In any case, that is not important. I agree that every SSA name in the
SSA table needs to have a DEF_STMT that is either (a) an empty
statement, or, (b) a valid statement still present in the IL.
Just
Hello,
> On Thu, 2006-12-21 at 20:18 +0100, Zdenek Dvorak wrote:
>
> > I think this might be a good idea. I think that this requires
> > a lot of changes (basically going through all uses of bsi_remove
> > and remove_phi_node and checking them), but it would be cleaner
> > than the current situa
Hi all,
I am working with GCC 4.1.1. I need some information on the following
Before emitting a call instruction, i need to check for function
attributes. Based on that i need to emit the corresponding call
instruction. For that, before emitting the call instruction, i check
for the attributes o
Hello Uros,
no the sizeof long is not always different. E.g. for future target 64bit
mingw the long type remains 4-byte size. But may we can use the
pointer-size ?
Because on i386 32-bit system sizeof(void *)==4 and on x86_64 64-bit
system sizeof(void *)==8 !
Regards,
i.A. Kai Tietz
Uros
Hello!
There is a fixme in config/i386/driver-i386.c:
--cut here--
if (arch)
{
/* FIXME: i386 is wrong for 64bit compiler. How can we tell if
we are generating 64bit or 32bit code? */
cpu = "i386";
}
else
--cut here--
Couldn't simple "sizeof(long)" do the trick here,
Dear GCC Developers / Users,
I am trying to port a GCC-Backend from GCC 2.7.2.3 to GCC 4.1.1. After
having had a look on some already existing backends like the PDP11, I
found out that there have been a lot of new Header-Files added to
".c" as includes.
My question is now whether some kind of sta
Or you can do, since elsewhere in the code you compute time_t_max:
for (j = 1; j <= time_t_max / 2 + 1; j *= 2)
No, this does not work. It would work to have:
for (j = 1;;)
{
if (j > time_t_max / 2)
break;
j *= 2;
}
Oops.
Paolo
Paul Eggert wrote:
Roberto Bagnara <[EMAIL PROTECTED]> writes:
(The platform I'm thinking of is Tandem NSK/OSS.)
Is this correct? Doesn't C99's 6.2.5#6 mandate that...
This is straying from the subject of GCC and into the
problems of writing portable C code, but since you asked
The Tan
int j;
for (j = 1; 0 < j; j *= 2)
if (! bigtime_test (j))
return 1;
Here it is obvious to a programmer that the comparison is
intended to do overflow checking, even though the test
controls the loop.
Well, it's not to me. :-)
Another question for the GCC expert
20 matches
Mail list logo
