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
Hi Segher,
This patch fixes a combiner bug in simplify_set which calls
CANNOT_CHANGE_MODE_CLASS with wrong mode params.
It occurs when trying to simplify paradoxical subregs of hw regs (whose
natural mode is lower than a word).
In fact, changing from (set x:m1
On 31/01/2017 22:15, Segher Boessenkool wrote:
> Hello,
>
> On Mon, Jan 30, 2017 at 10:43:23AM +0100, Aurelien Buhrig wrote:
>> This patch fixes a combiner bug in simplify_set which calls
>> CANNOT_CHANGE_MODE_CLASS with wrong mode params.
>> It occurs when trying to s
is the
most relevant for this patch though ...
OK to commit?
Aurélien
Changelog:
2017-01-27 Aurelien Buhrig <aurelien.buhrig@gmail.com>
* combine.c (simplify_set): Fix call to REG_CANNOT_CHANGE_MODE_CLASS_P
Index: gcc/com
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:
>>>>>
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))
>>
>>
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
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 (reg:HI 2 r2)
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 (reg:HI 2
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
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 47 2 (set (reg:SI 8 a1
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 word moves:
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 ]) 0)
(lshiftrt:SI (reg/v:SI 24 [ w ]) (const_int 31 [0x1f
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 [ w ]) (const_int 31 [0x1f]))
The register 21
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 iftmp.1 ]
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.
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 the
Le 02/05/2012 16:41, Ian Lance Taylor a écrit :
Aurelien Buhrig aurelien.buhrig@gmail.com 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 31 [0x1f
Passes bootstrap and regression test powerpc64-linux.
Thanks a lot, Alan!
So, Aurelien, you only need to adjust the formatting of the patch and post a
ChangeLog entry along with it. TIA.
Thanks Alan!
Bootstrap and regression test for m68k-elf ok, but I have trouble cross
compiling
Hi,
This patch (for 4.6) fixes a wrong subword index computation in
store_bit_field_1 for big endian targets when value is at least 4 times
bigger than a word (DI REG value with HI words).
It fixes a regression on gcc.c-torture/execute/bitfld-3.c for my current
backend port.
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, so that I can have a better
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 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_REGNO) 0) is not representable but
(subreg:HI (reg:PSI
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
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
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
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,
(subreg:HI (reg:PSI A0_REGNO) 0
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/looking at, so that I can have a better
Le 01/03/2012 11:09, Richard Guenther a écrit :
On Wed, Feb 29, 2012 at 6:02 PM, Aurelien Buhrig
aurelien.buhrig@gmail.com wrote:
Le 29/02/2012 17:08, Richard Guenther a écrit :
On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
aurelien.buhrig@gmail.com wrote:
Le 29/02/2012 16:15
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
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 in
Le 29/02/2012 16:15, Richard Guenther a écrit :
On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
aurelien.buhrig@gmail.com 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
have ptr_mode
Le 29/02/2012 17:08, Richard Guenther a écrit :
On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
aurelien.buhrig@gmail.com wrote:
Le 29/02/2012 16:15, Richard Guenther a écrit :
On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
aurelien.buhrig@gmail.com wrote:
The issue is most
Le 21/01/2012 03:37, Alan Modra a écrit :
The problem occurs when value is a REG and bitsize BITS_PER_WORD. This
is because wordnum, which is used to get the subword of value, is
incorrectly computed, in BIG_ENDIAN, wrt the number of words needed by
bitsize instead of the number of words
Hi,
I've found a bug in store_bit_field_1 for BIG_ENDIAN targets whose words
are HI. The testcase is execute.exp=bitfld-3.c for my target (which is
not public).
It occurs on 4.6.1 release, but seem to be present in trunk (looking at
the code, not executed).
The problem occurs when value is a
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 richard.guent...@gmail.com:
On Fri, Oct 21, 2011 at 4:53 PM, Aurelien Buhrig
aurelien.buhrig@gmail.com wrote:
Hi,
I'm trying to port gcc 4.6.1
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,
41 matches
Mail list logo
