C++ ABI and ILP64

[Zack Weinberg]

"Markus F.X.J. Oberhumer" <markus@oberhumer.com> writes:
> On Thursday 16 December 2004 21:03, Zack Weinberg wrote:
>> I'm pretty sure the as-if rule allows the optimization you want in
>> LP64 mode.  Your example code is
>>
>> > char *foo(char* base, long off, long shift) {
>> >    return base + (base[off] << shift);
>> > }
...
>> is that the first will reduce the left-shift count modulo 32 and the
>> second will reduce it modulo 64.  But shifting left by more than 31
>> (sizeof(int)*CHAR_BIT) is undefined behavior, so the compiler is
>> entitled to generate the second sequence for LP64.
>
> I don't think that's true - consider base[off] == 0x10 and shift == 31.
> Then (base[off] << shift) under LP64 has to be 0, so this optimization is only 
> valid under ILP64.

Bother, you're right.  I think the convenience of sticking to the same
ABI as everyone else is going to outweigh this comparatively minor
deoptimization, though.

You said this is simplified from some template code that you don't
think you can wedge an explicit cast into.  Can you show an example of
the real thing?  There's probably some way to get the semantics you
want without resorting to nonstandard ABIs.

Alternatively, I suppose we could add an extension that changes the
integer promotions in a lexically-scoped manner, something like

  char *foo(char* base, long off, long shift) {
    __with_integer_promotions_to(long) {
      return base + (base[off] << shift);
    }
  }

This construct causes everything inside its block to be interpreted as
if every occurrence of "int" in C99 6.3.1.1p2 were replaced with
"long", including within the phrase "unsigned int", but excluding the
clause about bitfields.  I'm not sure what that one covers that the
immediately preceding one doesn't, so I'm not sure how to change it to
make it consistent.

We're trying to avoid adding new extensions right now, though, so if
there's some other way to do what you want we aren't going to go for
this idea.

zw