> They (load, store, add) can modify flags before reload.
> (while no reload_in_progress)
> Is this OK ?
Yes.
r~
Denis Chertykov wrote:
I think that sequence of compare + cond-jump will exists in any
compiler pass.
Combine can optimize away compares, if you have other instructions that
set the condition code register to useful values. This optimization
will only work correctly if instructions that set or c
> 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
Bernardo Innocenti <[EMAIL PROTECTED]> writes:
> Denis Chertykov wrote:
>
> > I have converted the AVR port from CC0 to CCmode.
>
> That's indeed very good news. Incidentally, CC0
> conversion of the AVR target was being discussed
> in an off-list thread with Andy Hutchinson.
>
>
> > But may
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
Hi Denis,
I have had a look at your patch. It generally seems to work. Presently it
still misses some optimization where the old cc0 back-end was smarter. The
testsuite also reports a couple of new failures.
Yours,
Björn.
Here are a couple of cases where the old cc0 interface generated bette
Denis Chertykov wrote:
I have converted the AVR port from CC0 to CCmode.
That's indeed very good news. Incidentally, CC0
conversion of the AVR target was being discussed
in an off-list thread with Andy Hutchinson.
But may be I have converted the port in wrong way.
(It's because I was interested i
> 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
Hi All!
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 just because AV
25 matches
Mail list logo
