Re: Gcc plugin: error: ‘LAST_AND_UNUSED_RTX_CODE’ undeclared
Hi, --- On Fri, 26/2/10, Andrew Pinski wrote: > From the looks of it, you have a define for CONST as > const. This > first error is the reason for the rest of the errors. > > Thanks, > Andrew Pinski I havent modified anything in that part of the code. Reordering the header files somehow made all the errors disappear. Thanks, Ashish Jain The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc
Hello all, I am highly interestd in implementing C compiler for EFI Byte Code in gcc and participate in Google Summer Code. EFI is a much larger, more complex,OS-like replacement for the older BIOS firmware interface present in all IBM PC-compatible personal computers. and the EFI specification provides for a processor-independent device driver environment(like virtualmachine), called EFI Byte Code or EBC. Intel(R) C Compiler for EFI Byte Code, the only one C compiler for EFI Byte Code (http://sx.intel.com/p-553-intel-c-compiler-for-efi-byte-code.aspx) is not open source, and also a pay software. So i am wondering whether this kind of idea is valuable to the gcc community? or are there any other related ideas is more valuable? thanks yi-hong
Re: Change x86 default arch for 4.5?
On Mon, 22 Feb 2010, Erik Trulsson wrote: > As for the relative hurts. Code compiled for a newer CPU (making use > of newer instructions) will not run at all on older CPUs not supporting > those newer instructions. Much hurt there. > > On the other hand code compiled for an older CPU that is run a newer > CPU will run just fine, if slightly slower than they could have due > to not making use of new instructions in the newer CPU. That can well be seen as a point for _making_ the change: when it fails, the user/admin knows there is a need to adjust, whereas silent degradation will continue to make look GCC bad and hurt its traction and adoption (as Steven and others have experienced). Gerald
Re: [RFH] A simple way to figure out the number of bits used by a long double
On 26/02/2010 19:24, Ian Lance Taylor wrote: > Paolo Carlini writes: > >> I'm trying to simplify somewhat code in the library hashing floating >> point numbers, and I would find very useful a simple "recipe" giving the >> total number of bits actually used by a long double: the basic issue is >> that for formats like the 80-bit Intel, I can't just rely on sizeof, >> because the last 6 bytes are unused. At the moment I'm trying to cook up >> something fixing that count with LDBL_MANT_DIG, but maybe there is >> something simpler, maybe using preprocessor builtins?!? > > I saw that this led into a long discussion which I didn't fully > understand. I just want to comment that you can't reasonably hash > floating point representations by simply hashing the bits, even if you > can figure out how many bits there are. A hash function is > necessarily tied to an equality function, and when comparing floating > point numbers for equality some bits are ignored. In particular you > can have multiple representations of NaN, which for most hashing > purposes would be considered to be the same. Heh. sprintf() them into a buffer, then hash the string representation, which is effectively normalised. Use only a limited number of digits of precision because for a hash table false matches are fine, only false negatives matter. Of course the sprintf overhead would kill all the advantages of having a hash table. Maybe there's some other, cheaper "cheap trick" that could be used to normalise FP representations into something more easily hashable. At the very least, it sounds like hash-aux.cc should be fpclassify()ing its inputs, using the bits of the result from that as part of the hash tag, and only ever including bits from the actual fp operand for FP_NORMAL and FP_SUBNORMAL types. You might or might not want to hash in the sign bit as well to distinguish infinities. cheers, DaveK
Re: Gcc plugin: error: ‘LAST_AND_UNUSED_RTX_CODE’ undeclared
On Sat, Feb 27, 2010 at 12:55 AM, ashish jain wrote: > I havent modified anything in that part of the code. Reordering the header > files somehow made all the errors disappear. You should figure out what is doing the define of CONST then. Because from the sound of it, you are going to have problems if you try to use the CONST rtx code. Thanks, Andrew Pinski
optimizing the pushing of constant parameters to functions
I wonder whether there is a plan to optimize code such as this:
extern int (const int x);
void () {
(444);
(444);
}
by not pushing the constant argument twice. It seems safe to do so,
because the function called will not modify its argument on the stack.
The experiment I did with gcc 4.4.1 -O3 indicates this is not currently
being done, with this result:
movl$444, (%esp)
call
movl$444, (%esp)
call
The application I have in mind is putting a pointer to thread local
storage as the last argument for many functions.
Re: optimizing the pushing of constant parameters to functions
Sent from my iPhone
On Feb 27, 2010, at 10:17 AM, "Daniel R. Grayson"
wrote:
I wonder whether there is a plan to optimize code such as this:
extern int (const int x);
void () {
(444);
(444);
}
by not pushing the constant argument twice. It seems safe to do so,
because the function called will not modify its argument on the stack.
I can think of one case where this is not true. Sibcalling where
arguments are the same size and the order are different or just
different in general.
The experiment I did with gcc 4.4.1 -O3 indicates this is not
currently
being done, with this result:
movl$444, (%esp)
call
movl$444, (%esp)
call
The application I have in mind is putting a pointer to thread local
storage as the last argument for many functions.
Re: optimizing the pushing of constant parameters to functions
Quoting Andrew Pinski :
Sent from my iPhone
On Feb 27, 2010, at 10:17 AM, "Daniel R. Grayson" wrote:
I wonder whether there is a plan to optimize code such as this:
extern int (const int x);
void () {
(444);
(444);
}
by not pushing the constant argument twice. It seems safe to do so,
because the function called will not modify its argument on the stack.
I can think of one case where this is not true. Sibcalling where
arguments are the same size and the order are different or just
different in general.
In that case, the sibcall optimization really actually goes against the
function declaration. It's basically an ABI decision if we consider that
valid. If it's not valid for a target, then the push optimization should
be safe; this might be indicated by a target hook.
