> They (load, store, add) can modify flags before reload.
> (while no reload_in_progress)
> Is this OK ?
Yes.
r~
> 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 h
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 ...)))
> >>
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.
>
> 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)
>>(compare:HI (plus:HI (m
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
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
> operation
> 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
>>>
> 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.
>
> I
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
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, wh
> 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
> From: Björn Haase <[EMAIL PROTECTED]>
> 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. Th
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 t
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 so
> 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
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 intereste
> 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 registe
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 C
> 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_RE
20 matches
Mail list logo
