Hello !
I would like to use a fixed global register (here, as an applicative
stack pointer) and would like gcc (6.3 / private backend) to actually
optimize the following code using postinc/predec addressing mode on this
global fixed reg itself (a4 here) :
register int *ptr asm ("a4");
void pushi
On 09/01/2017 19:35, Jeff Law wrote:
> On 01/09/2017 07:02 AM, Aurelien Buhrig wrote:
>> On 06/01/2017 17:06, Jeff Law wrote:
>>> On 01/06/2017 03:20 AM, Aurelien Buhrig wrote:
>>>>
>>>>>> So the insn:
>>>>>> (set (reg:QI 0
On 06/01/2017 17:06, Jeff Law wrote:
> On 01/06/2017 03:20 AM, Aurelien Buhrig wrote:
>>
>>>> So the insn:
>>>> (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1))
>>>>
>>>> is transformed into:
>>>> (set (reg:SI
> Look at the dump file for reload to see where things come from. Also
> everything Jeff said; you really want LRA.
I will try switching to LRA in a second step, but I think I need first to
remove the old cc0...
BTW, in which way the LRA is better than IRA? Is there any benchmarks?
Thanks for
>> So the insn:
>> (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1))
>>
>> is transformed into:
>> (set (reg:SI 8 a0) (reg:SI 2 r2))
>> (set (reg:SI 8 a0) (const_int 1))
>> (set (reg:SI 8 a0) (plus:SI (reg:SI 8 a0) (reg:SI 8 a0)))
>> (set (reg:QI 0 r0) (mem:QI (reg:SI 8 a0))
>>
>> Th
Hi all, and best wishes for the happy new year!
I'm porting a private 4.6 backend to GCC 6 and facing a reload issue and
I would appreciate a little help to cope with it.
The issue happens when reloading:
(set (reg:QI 47 [ _9 ])
(mem:QI (plus:SI (reg/v/f:SI 68 [orig:51 in ] [51])
>> I'm porting a private backend from an old 4.6 branch to the 6.1.0
>> release, and I have some troubles eliminating my frame pointer without
>> -fomit-frame-pointer option.
>> Elimination is correctly done with -fomit-frame-pointer.
> If the target's default is -fno-omit-frame-pointer, then it's
Hi,
I'm porting a private backend from an old 4.6 branch to the 6.1.0
release, and I have some troubles eliminating my frame pointer without
-fomit-frame-pointer option.
Elimination is correctly done with -fomit-frame-pointer.
For an empty function (i.e. void f(void) {}), my hardware frame pointe
>>> In the following RTL, the hardware (reg:HI r2), whose natural mode is
>>> HImode, is set to 0, but when analysing the REG_EQUAL notes of the MULT
>>> insn during CSE pass, the (reg:SI r2) is computed to be equivalent to 0,
>>> which is wrong (the target is big endian).
>>>
>>> (insn 51 9 52 3
>> In the following RTL, the hardware (reg:HI r2), whose natural mode is
>> HImode, is set to 0, but when analysing the REG_EQUAL notes of the MULT
>> insn during CSE pass, the (reg:SI r2) is computed to be equivalent to 0,
>> which is wrong (the target is big endian).
>>
>> (insn 51 9 52 3 (set (r
Hi,
I'm trying to track a bug down on a private backend which occurs during
CSE pass (gcc-4.6.3, pr27364.c).
In the following RTL, the hardware (reg:HI r2), whose natural mode is
HImode, is set to 0, but when analysing the REG_EQUAL notes of the MULT
insn during CSE pass, the (reg:SI r2) is compu
09/05/2012 11:16, Eric Botcazou:
>> I have another issue in DCE pass after changing word_mode from SImode to
>> HImode.
>> Indeed, in subreg1 pass, SI moves such as
>> ...
>> (insn 42 41 43 (set (reg:SI 85) (reg/f:SI 83))
>> (insn 46 45 47 (set (reg:SI 8 a1) (reg:SI 85))
>>
>> are split into HImode
07/05/2012 17:53, Aurelien Buhrig :
>
> I have another issue in DCE pass after changing word_mode from SImode to
> HImode.
> (insn 98 97 99 2 (set (subreg:HI (reg:SI 106) 0) (reg:HI 104))
> (insn 99 98 100 2 (set (subreg:HI (reg:SI 106) 2) (reg:HI 105 [+2 ]))
> (insn 100 99 4
04/05/2012 09:37, Aurelien Buhrig :
> 03/05/2012 14:14, Aurelien Buhrig :
>> 02/05/2012 21:36, Eric Botcazou :
>>>> I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
>>>> this insn:
>>>> (set (subreg:SI (reg:QI 21 [ iftmp.1
Le 03/05/2012 14:14, Aurelien Buhrig a écrit :
> 02/05/2012 21:36, Eric Botcazou :
>>> I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
>>> this insn:
>>> (set (subreg:SI (reg:QI 21 [ iftmp.1 ]) 0)
>>> (lshiftrt:SI (reg/v:SI 24 [
02/05/2012 21:36, Eric Botcazou :
>> I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
>> this insn:
>> (set (subreg:SI (reg:QI 21 [ iftmp.1 ]) 0)
>> (lshiftrt:SI (reg/v:SI 24 [ w ]) (const_int 31 [0x1f]))
>>
>> The register 21 is reloaded into
>> (reg:QI 0 r0 [orig:21 i
Le 02/05/2012 16:41, Ian Lance Taylor a écrit :
> Aurelien Buhrig writes:
>
>> I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
>> this insn:
>> (set (subreg:SI (reg:QI 21 [ iftmp.1 ]) 0)
>> (lshiftrt:SI (reg/v:SI 24 [ w ]) (const_int
> Ben Morgan wrote:
>
>> In a course at my university (Universität Würzburg, Germany) we have created
>> a 32-bit RISC CPU architecture -- the HaDesXI-CPU -- (in VHDL) which we then
>> play onto a FPGA (the Xilinx Spartan-3AN) to use. So far if we want to do
>> anything with it, we have to write
Hi,
I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
this insn:
(set (subreg:SI (reg:QI 21 [ iftmp.1 ]) 0)
(lshiftrt:SI (reg/v:SI 24 [ w ]) (const_int 31 [0x1f]))
The register 21 is reloaded into
(reg:QI 0 r0 [orig:21 iftmp.1 ] [21]), which is a HI-wide hw register.
S
>> Hi,
>>
>> I'm trying to make some peephole2 optimizations working (gcc 4.6.1), but
>> it seems the REG_DEAD information is lost during or after reload.
>>
>> In the following peephole2 definition, peep2_reg_dead_p returns false,
>> whereas REG_DEAD information is correctly set before reload for
09/03/2012 17:10, Bernd Schmidt:
> On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
>> I'm not used to work at tree level for now and it is unclear for me what
>> part of the code should be tweaked. Can you tell me which part of the
>> code you are fixing/looking at, s
> On 03/09/2012 11:20 AM, Aurelien Buhrig wrote:
>> Hi,
>>
>> It seems there is an issue around subreg:HI of PSI hardware register,
>> which occurs either during expand or reload (GCC 4.6.1).
>>
>> For my big endian target,
>> (subreg:HI (reg:PSI A0_REG
> Hi,
>
> I'm trying to make some peephole2 optimizations working (gcc 4.6.1), but
> it seems the REG_DEAD information is lost during or after reload.
>
> In the following peephole2 definition, peep2_reg_dead_p returns false,
> whereas REG_DEAD information is correctly set before reload for
> ope
Hi,
I'm trying to make some peephole2 optimizations working (gcc 4.6.1), but
it seems the REG_DEAD information is lost during or after reload.
In the following peephole2 definition, peep2_reg_dead_p returns false,
whereas REG_DEAD information is correctly set before reload for
operands[0] on the
Le 09/03/2012 17:10, Bernd Schmidt a écrit :
> On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
>> I'm not used to work at tree level for now and it is unclear for me what
>> part of the code should be tweaked. Can you tell me which part of the
>> code you are fixing/lookin
09/03/2012 15:08, Bernd Schmidt :
> On 03/09/2012 11:20 AM, Aurelien Buhrig wrote:
>> Hi,
>>
>> It seems there is an issue around subreg:HI of PSI hardware register,
>> which occurs either during expand or reload (GCC 4.6.1).
>>
>> For my big endian target,
Hi,
It seems there is an issue around subreg:HI of PSI hardware register,
which occurs either during expand or reload (GCC 4.6.1).
For my big endian target,
(subreg:HI (reg:PSI A0_REGNO) 0) is not representable but
(subreg:HI (reg:PSI A0_REGNO) 2) is (reg:HI A0_REGNO).
The issue occurs when stor
Le 01/03/2012 11:09, Richard Guenther a écrit :
> On Wed, Feb 29, 2012 at 6:02 PM, Aurelien Buhrig
> wrote:
>> Le 29/02/2012 17:08, Richard Guenther a écrit :
>>> On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
>>> wrote:
>>>> Le 29/02/2012 16:15, Richa
Le 29/02/2012 17:08, Richard Guenther a écrit :
> On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
> wrote:
>> Le 29/02/2012 16:15, Richard Guenther a écrit :
>>> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
>>> wrote:
>>>>
>>>>> Th
Le 29/02/2012 16:15, Richard Guenther a écrit :
> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
> wrote:
>>
>>> The issue is most probably that on GIMPLE we only deal with ptr_mode,
>>> not Pmode, and IVOPTs thinks that pointer induction variables will
>>&g
> The issue is most probably that on GIMPLE we only deal with ptr_mode,
> not Pmode, and IVOPTs thinks that pointer induction variables will
> have ptr_mode. To fix this the cost computation would need to take
> into account ptr_mode to Pmode conversions _and_ would need to
> consider Pmode IVs i
Hi,
I'm porting a gcc backend (4.6.1) for a 16-bit MCU with PSI pmode, and
SI ptr_mode.
I have a QoR problem with loops: the chosen IVs are often not good.
I looked at tree-ssa-loop-ivopts.c but it is hard to understand that
code. So sorry if my questions are a bit confused but I would like to
un
Indeed, ptr_mode!=Pmode for my target.
I will try to figure out where such a Pmode comes from.
Thanks,
Aurélien
2011/10/23 Richard Guenther :
> On Fri, Oct 21, 2011 at 4:53 PM, Aurelien Buhrig
> wrote:
>> Hi,
>>
>> I'm trying to port gcc 4.6.1 for a new target for
Hi,
I'm trying to port gcc 4.6.1 for a new target for which Pmode=PSI.
I have an ICE in size_binop_loc, at fold-const.c:1433 when compiling
gcc.c-torture/compile/92-1.c
Here is the back trace
#1 0x0060f8f3 in size_binop_loc (loc=0, code=PLUS_EXPR,
arg0=0x2e8d8150, arg1=0x2e8
34 matches
Mail list logo
