They (load, store, add) can modify flags before reload.
(while no reload_in_progress)
Is this OK ?
Yes.
r~
Richard Henderson [EMAIL PROTECTED] writes:
On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote:
The reload will generate addhi3 and reload will have a problem with
two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
surprise for reload. :( As I remember.
In
Paul Schlie [EMAIL PROTECTED] writes:
From: Denis Chertykov [EMAIL PROTECTED]
- possibly something like: ?
(define_insn *addhi3
[(set (match_operand:HI 0 ...)
(plus:HI (match_operand:HI 1 ...)
(match_operand:HI 2 ...)))
(set (reg ZCMP_FLAGS)
From: Denis Chertykov [EMAIL PROTECTED]
Paul Schlie [EMAIL PROTECTED] writes:
...
(Observing that I'm basically suggesting treating the cc-status register
like any other hard register, who's value would need to be saved/restored
around any corrupting operation if it's value has live
Paul Schlie [EMAIL PROTECTED] writes:
[...]
I think that better to support
cmpHI, cbranch - cmpQI1_set_CC, cmpQI2_use_CC, cbranch. because
AVR is a microcontroller and code size more important than code speed.
- I fully agree that code-size tends to be most important, which is why
On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote:
The reload will generate addhi3 and reload will have a problem with
two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
surprise for reload. :( As I remember.
In order to expose the flags register before reload, you
From: Richard Henderson [EMAIL PROTECTED]
On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote:
The reload will generate addhi3 and reload will have a problem with
two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
surprise for reload. :( As I remember.
In order to
From: Paul Schlie [EMAIL PROTECTED]
From: Richard Henderson [EMAIL PROTECTED]
On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote:
The reload will generate addhi3 and reload will have a problem with
two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
surprise for
On Sun, Mar 20, 2005 at 12:06:31PM -0500, Paul Schlie wrote:
- so in AVR's case, simply pretending that add operations don't modify
CC state may only be asking for trouble; however may it be sufficient to
somehow force spill/reload to only use indexed/auto-inc/dec load/store
operations,
On Sun, Mar 20, 2005 at 12:41:39PM -0500, Paul Schlie wrote:
- what about blk moves? (as they would seem to most likely destructively
modify the machine's cc state in most implementations, as their
implementation implies a conditional loop; or are they an exception?
if so, why?)
Why
Paul Schlie [EMAIL PROTECTED] writes:
From: Denis Chertykov [EMAIL PROTECTED]
Paul Schlie [EMAIL PROTECTED] writes:
Denis wrote:
I have converted the AVR port from CC0 to CCmode.
But may be I have converted the port in wrong way.
(It's because I was interested in *this* way.)
I
From: Denis Chertykov [EMAIL PROTECTED]
Paul Schlie [EMAIL PROTECTED] writes:
From: Denis Chertykov [EMAIL PROTECTED]
- although I agree that there's likely a cleaner more consistent way
to accurately describe and track condition-code side-effects of AVR's
ISA, it seems that this
Sorry meant denote the setting of FLAG_REGS based solely on it's result,
which should be implied by operand 0, the target of 3-operand instructions;
with the exception of compare, as it's effective target are the FLAGS_REGS.
corrected below:
From: Paul Schlie [EMAIL PROTECTED]
- possibly
Hi Paul,
I have the impression that you are trying to open open doors :-) : If IIUC
what Denis aims to do is to segment the re-organization of the back-end into
several independent small steps. One step will be the cc0 - CC_mode issue he
is addressing now. The splitting issue would be one of
From: Björn Haase [EMAIL PROTECTED]
In my opinion segmenting the rework of the back-end would indeed be the best
approach, also because I expect that the instruction patterns *with*
splitting will be fairly different. E.g. I do not think that the addsi3
will be present any more. So it would
Denis wrote:
I have converted the AVR port from CC0 to CCmode.
But may be I have converted the port in wrong way.
(It's because I was interested in *this* way.)
I have used CCmode register and havn't added the
'(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the
CC_REGNUM
Paul Schlie [EMAIL PROTECTED] writes:
Denis wrote:
I have converted the AVR port from CC0 to CCmode.
But may be I have converted the port in wrong way.
(It's because I was interested in *this* way.)
I have used CCmode register and havn't added the
'(clobber (reg:QI CC_REGNUM))' to
From: Denis Chertykov [EMAIL PROTECTED]
Paul Schlie [EMAIL PROTECTED] writes:
Denis wrote:
I have converted the AVR port from CC0 to CCmode.
But may be I have converted the port in wrong way.
(It's because I was interested in *this* way.)
I have used CCmode register and havn't added the
18 matches
Mail list logo
