Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2017-01-17 Thread Segher Boessenkool
Hi Eric, On Mon, Nov 07, 2016 at 10:44:44AM +0100, Eric Botcazou wrote: > Tested on PowerPC64/Linux, OK for the mainline? > > >* config/rs6000/rs6000.c (rs6000_emit_move): Also use a TOC reference > after forcing to constant memory when the code model is medium. Sorry I lost

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-11-07 Thread Eric Botcazou
> Now you don't need to have a special pool to call create_TOC_reference, you > can call it for regular TOC references as well, as done a few lines above: > > /* If this is a SYMBOL_REF that refers to a constant pool entry, >and we have put it in the TOC, we just need to make a

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-18 Thread Eric Botcazou
> I don't fully understand what you mean. This code was created for > PR65810, if that helps? OK, let's turn it into "mode" then, this doesn't change anything. -- Eric Botcazou

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-18 Thread Segher Boessenkool
On Tue, Oct 18, 2016 at 08:37:47PM +0200, Eric Botcazou wrote: > > We need to pass the mode of the actual datum we would put in the TOC to > > the use_toc_relative_ref function, not the mode of its address. > > Right, but this mode is not "mode", the TOC contains only Pmode entries if > the >

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-18 Thread Eric Botcazou
> We need to pass the mode of the actual datum we would put in the TOC to > the use_toc_relative_ref function, not the mode of its address. Right, but this mode is not "mode", the TOC contains only Pmode entries if the special constant pool is excluded. -- Eric Botcazou

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-18 Thread Segher Boessenkool
On Tue, Oct 18, 2016 at 01:09:24PM +0200, Eric Botcazou wrote: > > > No, "mode" is the mode of the MEM, not that of the SYMBOL_REF. > > > > I still don't see it, could you explain a bit more? > > MODE is the mode of operands[1] before: > > operands[1] = force_const_mem (mode,

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-18 Thread Eric Botcazou
> > No, "mode" is the mode of the MEM, not that of the SYMBOL_REF. > > I still don't see it, could you explain a bit more? MODE is the mode of operands[1] before: operands[1] = force_const_mem (mode, operands[1]); and after. But the test is on the address of the MEM, not on the MEM

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-18 Thread Segher Boessenkool
[ sorry for losing track of this patch ] On Sun, Oct 09, 2016 at 10:32:51AM +0200, Eric Botcazou wrote: > > Use "mode" instead of "Pmode" here? > > No, "mode" is the mode of the MEM, not that of the SYMBOL_REF. I still don't see it, could you explain a bit more? Segher

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-09 Thread Eric Botcazou
> Why does this not fail on darwin? It can reach this code afaics, and > it has ASM_OUTPUT_SPECIAL_POOL_ENTRY_P always 0. Probably because Darwin doesn't use the TOC at all. > Use "mode" instead of "Pmode" here? No, "mode" is the mode of the MEM, not that of the SYMBOL_REF. -- Eric Botcazou

Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-08 Thread Segher Boessenkool
Hi! On Sat, Oct 08, 2016 at 07:53:42PM +0200, Eric Botcazou wrote: > this fixes reload failures in 64-bit mode with -mcmodel=medium for targets > that define ASM_OUTPUT_SPECIAL_POOL_ENTRY_P to 0; that's the case for the > VxWorks port we'll submit because of the compatibility with the system >

[rs6000] Fix reload failures in 64-bit mode with no special constant pool

2016-10-08 Thread Eric Botcazou
Hi, this fixes reload failures in 64-bit mode with -mcmodel=medium for targets that define ASM_OUTPUT_SPECIAL_POOL_ENTRY_P to 0; that's the case for the VxWorks port we'll submit because of the compatibility with the system linker, which rejects .got sections in object files. When reload ends