On 08 January 2008 15:36, Dave Korn wrote:
> On 07 January 2008 21:15, Mark Mendell wrote:
>
>> A question was raised: Are side effects in the second parameter guaranteed
>> to be executed? Is it valid for a compiler to ignore any side effects?
>
> That perked up my curiosity:
>
> " The va
On 07 January 2008 21:15, Mark Mendell wrote:
> A question was raised: Are side effects in the second parameter guaranteed
> to be executed? Is it valid for a compiler to ignore any side effects?
That perked up my curiosity:
" The value of C must be a compile-time constant. "
Can a comp
06/01/2008 02:42 PM
Subject: Re: __builtin_expect for
Mark Mitchell writes:
> What do people think? Do we have the leeway to change this?
If it were just cases where using __builtin_expect is pointless that
would break, like function overloading and sizeof then I don't think
it would be a problem. However, it would change behaviour when C++
convers
Richard Guenther wrote:
>> What do people think? Do we have the leeway to change this? Or should
>> we add __builtin_expect2? Or add an -fno-polymorphic-builtin-expect?
>> Or...?
>
> I think we should simply make __builtin_expect polymorphic, but make sure
> to promote integral arguments with
On Jan 5, 2008 6:43 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > Currently, the prototype for __builtin_expect is
> >
> > long __builtin_expect (long expression, long constant);
> >
> > Extending it to functions would change it to
> >
> > T __builtin_expect
[EMAIL PROTECTED] wrote:
> Currently, the prototype for __builtin_expect is
>
> long __builtin_expect (long expression, long constant);
>
> Extending it to functions would change it to
>
> T __builtin_expect (T expression, T expected);
Yes, it really makes more sense for __builtin_expe
> >
> > which returns the value of FP with the same type as FP, and tells the
> > compiler that PFP is the expected target of FP. Trival examples:
> >
> > typedef void (*fptr_t)(void);
> >
> > extern void foo(void);
> >
> > void
> > call_fp (fptr_t fp)
> > {
> > /* Call the function
If possible, I agree it seems natural to extend __builtin_expect. My
concern would be backwards compatibility.
Currently, the prototype for __builtin_expect is
long __builtin_expect (long expression, long constant);
Extending it to functions would change it to
T __builtin_expect (T exp
Hans-Peter Nilsson wrote:
> On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote:
>> When we can't hint the real target, we want to hint the most common
>> target. There are potentially clever ways for the compiler to do this
>> automatically, but I'm most interested in giving the user some way to do
>>
On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote:
> When we can't hint the real target, we want to hint the most common
> target. There are potentially clever ways for the compiler to do this
> automatically, but I'm most interested in giving the user some way to do
> it explicitly. One possiblity i
[EMAIL PROTECTED] wrote:
> Are there any comments about the name, semantics, or usefulness of this
> extension?
>
Sounds very useful for SPU code. I look forward to trying it out.
Toying with the idea, the following seems like a potentially useful C++
form of the proposed extension :
struct
12 matches
Mail list logo
