Quoting DJ Delorie :
I was talking about what addresses are allowed by the
TARGET_LEGITIMATE_ADDRESS_P, not what the hardware implements or
what the register allocator is guided to produce; some optimizers
can get quite 'creative' in mashing rtl together.
I've never seen it actually do that
> I was talking about what addresses are allowed by the
> TARGET_LEGITIMATE_ADDRESS_P, not what the hardware implements or
> what the register allocator is guided to produce; some optimizers
> can get quite 'creative' in mashing rtl together.
I've never seen it actually do that and get it past th
Quoting DJ Delorie :
m32c.c:m32c_legitimate_address_p allows any rubbish inside a
PRE_MODIFY, as long as the address register is the stack pointer.
OTOH, it does not define any HAVE_*_MODIFY_* macro.
m32c has push/pop and no other pre/post modify
I was talking about what addresses are allow
> m32c.c:m32c_legitimate_address_p allows any rubbish inside a
> PRE_MODIFY, as long as the address register is the stack pointer.
> OTOH, it does not define any HAVE_*_MODIFY_* macro.
m32c has push/pop and no other pre/post modify
Quoting amyl...@spamcop.net:
The issue with this patch is that we'll have to check if gen_add3_insn might
fail on any target, and also we have to identify on which targets it will
create an insn that clobbers potentially live hard registers
(like a flags register), and make the substitution fail
Quoting Hans-Peter Nilsson :
On Fri, 23 Sep 2011, Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
> My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future
On Fri, 23 Sep 2011, Joern Rennecke wrote:
> Quoting "Paulo J. Matos" :
>
> > My addition instruction sets all the flags. So I have:
>
> This is annoying, but can be handled. Been there, done that.
> dse.c needs a small patch, which I intend to submit sometime in the future.
Could you be persuad
On Fri, 23 Sep 2011 09:30:48 -0400, amylaar wrote:
> Hiding the flags register would mean it is not represented in the rtl at
> all. You can have combined compare-branch instructions. Of course,
> going that route would mean that the model you present to GCC is even
> further from the hardware th
Quoting "Paulo J. Matos" :
That's seriously annoying. The idea was to ditch cc0 and explicitly
represent CC in a register to perform optimizations like splitting add
and addc for a double word addition. If by hiding my register flags
means going back to cc0, then it seems that the only way to go
On 23/09/11 08:21, Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future.
Ok. Actually I was quite happy
Quoting "Paulo J. Matos" :
My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future.
And all my (define_insn "*mov..." are tagged with a (clobber (reg:CC
RCC
Hi,
After the discussion about the use of CCmode in:
http://gcc.gnu.org/ml/gcc/2011-07/msg00303.html
I am trying to ditch support for the only cc0 attr and add support for
CC_REG.
There are two issues that are making the situation more complicated,
both of similar nature.
My addition instr
12 matches
Mail list logo
