Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-19 Thread Uros Bizjak
On Tue, Jul 19, 2011 at 1:25 PM, Richard Sandiford wrote: >> On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu wrote: > Yes, this is an example from PR I am referring to. Did you try to > define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this. > They make things even more comp

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-19 Thread Richard Sandiford
Uros Bizjak writes: > On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu wrote: Yes, this is an example from PR I am referring to. Did you try to define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this. >>> >>> They make things even more complex. ix86_simplify_base_index_disp >>> is cal

[PATCH, i386]: FixPR47744; [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403 [was: Re: PATCH [5/n] X32: Supprot 32bit address]

2011-07-18 Thread Uros Bizjak
Hello! This alternative patch fixes the problem in ix86_decompose_address, uncovered by x32 branch. Since x32 branch generates lots of SImode subreg of DImode values to handle Pmode vs. ptr_mode restrictions, a latent bug in x86_decompose_address allowed addresses in the (invalid, see SImode subre

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-16 Thread Uros Bizjak
On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu wrote: >>> Yes, this is an example from PR I am referring to. Did you try to >>> define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this. >>> >> >> They make things even more complex. ix86_simplify_base_index_disp >> is called after reload is done si

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-16 Thread H.J. Lu
On Fri, Jul 15, 2011 at 10:18 AM, H.J. Lu wrote: > On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak wrote: >> On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu wrote: >> >> If the first form of the address is not OK (it does not represent the >> hardware operation), then it should not enter into the

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread H.J. Lu
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak wrote: > On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu wrote: > > If the first form of the address is not OK (it does not represent the > hardware operation), then it should not enter into the insn stream. > This means, that it should be fixed (

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread H.J. Lu
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak wrote: > On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu wrote: > > If the first form of the address is not OK (it does not represent the > hardware operation), then it should not enter into the insn stream. > This means, that it should be fixed (

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread Uros Bizjak
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu wrote: If the first form of the address is not OK (it does not represent the hardware operation), then it should not enter into the insn stream. This means, that it should be fixed ("legitimized") to second form by appropriate function

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread H.J. Lu
On Fri, Jul 15, 2011 at 9:01 AM, Uros Bizjak wrote: > On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu wrote: > >> TARGET_MEM_REF only works on ptr_mode.  That means base and index parts >> of x86 address operand in x32 mode may be in ptr_mode.  This patch >> supports 32bit base and index par

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread Uros Bizjak
On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu wrote: > TARGET_MEM_REF only works on ptr_mode.  That means base and index parts > of x86 address operand in x32 mode may be in ptr_mode.  This patch > supports 32bit base and index parts in x32 mode.  OK for trunk? > > Thanks. > >>

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread H.J. Lu
On Fri, Jul 15, 2011 at 8:25 AM, Uros Bizjak wrote: > On Fri, Jul 15, 2011 at 3:03 PM, H.J. Lu wrote: >> On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak wrote: >>> On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu wrote: >>> TARGET_MEM_REF only works on ptr_mode.  That means base and index parts

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread Uros Bizjak
On Fri, Jul 15, 2011 at 3:03 PM, H.J. Lu wrote: > On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak wrote: >> On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu wrote: >> >>> TARGET_MEM_REF only works on ptr_mode.  That means base and index parts >>> of x86 address operand in x32 mode may be in ptr_mode.  Thi

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread H.J. Lu
On Fri, Jul 15, 2011 at 5:49 AM, Uros Bizjak wrote: > On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu wrote: > >> TARGET_MEM_REF only works on ptr_mode.  That means base and index parts >> of x86 address operand in x32 mode may be in ptr_mode.  This patch >> supports 32bit base and index parts in x32 m

Re: PATCH [5/n] X32: Supprot 32bit address

2011-07-15 Thread Uros Bizjak
On Sun, Jul 10, 2011 at 12:20 AM, H.J. Lu wrote: > TARGET_MEM_REF only works on ptr_mode.  That means base and index parts > of x86 address operand in x32 mode may be in ptr_mode.  This patch > supports 32bit base and index parts in x32 mode.  OK for trunk? > > Thanks. > > > H.J. > --- > 2011-07-

PATCH [5/n] X32: Supprot 32bit address

2011-07-09 Thread H.J. Lu
Hi, TARGET_MEM_REF only works on ptr_mode. That means base and index parts of x86 address operand in x32 mode may be in ptr_mode. This patch supports 32bit base and index parts in x32 mode. OK for trunk? Thanks. H.J. --- 2011-07-09 H.J. Lu * config/i386/i386.c (ix86_simplify_base