Will backend ever see an memory operand with address wrap around?
Hi, I am trying to optimize memory address for x32. X32 runs in 64-bit mode. 64-bit address is base + index * scale + offset: 1. Base is 64bit. 2. Index is 64bit. 3. Offset is 8bit or 32bit 0x67 address size prefix is used to zero-extend 32bit address to 64bit: 1. Upper 32bits of base or index can be none-zero. 2. Index can be negative. We can avoid 0x67 prefix if 1. There is no index 2. Upper 32bits of base is zero: a. When base is set via 32bit load op, the upper 32bits are atomically zero-extended from the lower 32bits 3. Base + offset is a valid 32-bit address. Will x86 backend ever see a memory address with wrap around. That is to use 0x + 0x30 to represent 0x2f. Thanks. -- H.J.
Back end for DCPU-16 architecture
Hi all, I have started work on a new gcc back-end for the DCPU-16 architecture. DCPU-16 is a virtual processor that is supposed to be an in-game feature of the upcoming game 0x10c (see http://0x10c.com) The project is hosted at https://github.com/frot/gcc-dcpu16. Nothing to see there yet. I have a "bunch" of #defines to wade through first... Regards, Fredrik Rothamel
Re: Will backend ever see an memory operand with address wrap around?
On Sun, May 13, 2012 at 6:32 PM, H.J. Lu wrote:
> Hi,
>
> I am trying to optimize memory address for x32. X32 runs in 64-bit mode.
> 64-bit address is base + index * scale + offset:
> 1. Base is 64bit.
> 2. Index is 64bit.
> 3. Offset is 8bit or 32bit
>
> 0x67 address size prefix is used to zero-extend 32bit address to 64bit:
> 1. Upper 32bits of base or index can be none-zero.
> 2. Index can be negative.
>
> We can avoid 0x67 prefix if
> 1. There is no index
> 2. Upper 32bits of base is zero:
> a. When base is set via 32bit load op, the upper 32bits are
> atomically zero-extended from the lower 32bits
> 3. Base + offset is a valid 32-bit address.
>
> Will x86 backend ever see a memory address with wrap around.
> That is to use 0x + 0x30 to represent 0x2f.
Why not? Easily from code like
long foo (long a, long b)
{
return *((long *)(a + b));
}
no?
Richard.
> Thanks.
>
>
> --
> H.J.
Re: Will backend ever see an memory operand with address wrap around?
On Sun, May 13, 2012 at 12:01 PM, Richard Guenther
wrote:
> On Sun, May 13, 2012 at 6:32 PM, H.J. Lu wrote:
>> Hi,
>>
>> I am trying to optimize memory address for x32. X32 runs in 64-bit mode.
>> 64-bit address is base + index * scale + offset:
>> 1. Base is 64bit.
>> 2. Index is 64bit.
>> 3. Offset is 8bit or 32bit
>>
>> 0x67 address size prefix is used to zero-extend 32bit address to 64bit:
>> 1. Upper 32bits of base or index can be none-zero.
>> 2. Index can be negative.
>>
>> We can avoid 0x67 prefix if
>> 1. There is no index
>> 2. Upper 32bits of base is zero:
>> a. When base is set via 32bit load op, the upper 32bits are
>> atomically zero-extended from the lower 32bits
>> 3. Base + offset is a valid 32-bit address.
>>
>> Will x86 backend ever see a memory address with wrap around.
>> That is to use 0x + 0x30 to represent 0x2f.
>
> Why not? Easily from code like
>
> long foo (long a, long b)
> {
> return *((long *)(a + b));
> }
>
What is the expect run-time behavior when a + b has
overflow/underflow?
--
H.J.
gcc-4.8-20120513 is now available
Snapshot gcc-4.8-20120513 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120513/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 187445 You'll find: gcc-4.8-20120513.tar.bz2 Complete GCC MD5=ef0718156d56776d34267e1a24a99929 SHA1=d23eac2ac4b087811bd2380ae40f2bacd9457809 Diffs from 4.8-20120506 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Will backend ever see an memory operand with address wrap around?
Quoting "H.J. Lu" : Will x86 backend ever see a memory address with wrap around. Actually, just this kind of problem made the indexed addressing mode for SH64 for the ABIs with 32 bit addresses unusable. If your MMU supports it, you can try to map the second 4 GB * maximum scale mapped to the first 4 GB, to get effectively zero-extending semantics for the supported addressing modes.
Re: Will backend ever see an memory operand with address wrap around?
Quoting "H.J. Lu" : What is the expect run-time behavior when a + b has overflow/underflow? The expectation is wrap-around. Note that loop strenght reduction can cause assumed wrap-around semantics in RTL for strictly conforming C input where no such wrap-around is in evidence.
Re: Will backend ever see an memory operand with address wrap around?
On Sun, May 13, 2012 at 6:17 PM, wrote: > Quoting "H.J. Lu" : > >> What is the expect run-time behavior when a + b has >> overflow/underflow? > > > The expectation is wrap-around. Note that loop strenght reduction can > cause assumed wrap-around semantics in RTL for strictly conforming C input > where no such wrap-around is in evidence. I noticed that also. But my impression is loop strength reduction doesn't use wrap-around address for load/store directly. -- H.J.
Re: Will backend ever see an memory operand with address wrap around?
On May 13, 2012, at 21:17, amyl...@spamcop.net wrote: > The expectation is wrap-around. Note that loop strenght reduction can > cause assumed wrap-around semantics in RTL for strictly conforming C input > where no such wrap-around is in evidence. Really, we should define signed integer arithmetic in RTL to always be wrap-around. While there may (*) be some benefit in "taking advantage" of undefined semantics of integer overflow in early tree optimizers (computing number of loop iterations etc.), at the same time it also reduces optimization opportunities. Transformations cannot introduce overflows where none existed before, so integer addition and subtraction are not associative. In the end, the hardware is deterministic and does have wrap-around semantics. So, it really doesn't make sense to pretend in RTL that it doesn't. -Geert -- (*) At the end of the day, I think everybody would win by unambiguously defining signed integer arithmetic as using wrap-around semantics everywhere. Software is hard enough with defined semantics.
Re: Will backend ever see an memory operand with address wrap around?
Quoting "H.J. Lu" :
On Sun, May 13, 2012 at 6:17 PM, wrote:
Quoting "H.J. Lu" :
What is the expect run-time behavior when a + b has
overflow/underflow?
The expectation is wrap-around. Note that loop strenght reduction can
cause assumed wrap-around semantics in RTL for strictly conforming C input
where no such wrap-around is in evidence.
I noticed that also. But my impression is loop strength reduction doesn't
use wrap-around address for load/store directly.
I've actually seen it for loop strength reduction, but here is
an example that does not even involve loop strength reduction to
get into trouble - it just involves the distributive law in the
indexed access itself:
extern int a[];
void f (int o)
{
int i;
for (i = C; i < C + 100; i++)
{
a[o-i] = 0;
}
}
At -O2, gcc (GCC) 4.7.0 20120504 (Red Hat 4.7.0-4) for i686 gives:
f:
.LFB0:
.cfi_startproc
movl4(%esp), %ecx
movl$100, %eax
.p2align 4,,7
.p2align 3
.L2:
leal(%eax,%ecx), %edx
subl$1, %eax
movl$0, a-120400(,%edx,4)
jne .L2
rep
ret
.cfi_endproc
Now consider what happens if o == C, and a is within the first GB.
unless the base address is encoded as 64 bit, you'll have an overflow.
Re: Will backend ever see an memory operand with address wrap around?
On Sun, May 13, 2012 at 8:16 PM, Joern Rennecke wrote:
> Quoting "H.J. Lu" :
>
>> On Sun, May 13, 2012 at 6:17 PM, wrote:
>>>
>>> Quoting "H.J. Lu" :
>>>
What is the expect run-time behavior when a + b has
overflow/underflow?
>>>
>>>
>>>
>>> The expectation is wrap-around. Note that loop strenght reduction can
>>> cause assumed wrap-around semantics in RTL for strictly conforming C
>>> input
>>> where no such wrap-around is in evidence.
>>
>>
>> I noticed that also. But my impression is loop strength reduction doesn't
>> use wrap-around address for load/store directly.
>
>
> I've actually seen it for loop strength reduction, but here is
> an example that does not even involve loop strength reduction to
> get into trouble - it just involves the distributive law in the
> indexed access itself:
>
> extern int a[];
>
> void f (int o)
> {
> int i;
> for (i = C; i < C + 100; i++)
> {
> a[o-i] = 0;
> }
> }
>
> At -O2, gcc (GCC) 4.7.0 20120504 (Red Hat 4.7.0-4) for i686 gives:
>
> f:
> .LFB0:
> .cfi_startproc
> movl 4(%esp), %ecx
> movl $100, %eax
> .p2align 4,,7
> .p2align 3
> .L2:
> leal (%eax,%ecx), %edx
> subl $1, %eax
> movl $0, a-120400(,%edx,4)
> jne .L2
> rep
> ret
> .cfi_endproc
>
> Now consider what happens if o == C, and a is within the first GB.
> unless the base address is encoded as 64 bit, you'll have an overflow.
What is the run-time result when overflow happens?
--
H.J.
Re: Will backend ever see an memory operand with address wrap around?
Quoting "H.J. Lu" : What is the run-time result when overflow happens? Assuming you use a 32 bit unsigned base address, and the space beyond 4G is unmapped, you'll get a SEGV.
