> From: Alexandre Oliva <[EMAIL PROTECTED]>
>> On Mar 28, 2005, Paul Schlie <[EMAIL PROTECTED]> wrote:
>
>> More specifically, if GCC enabled set to optionally specify multiple targets
>> for a single rtl source expression, i.e.:
>
>> (set ((reg:xx %0) (reg CC) ...) (some-expression:xx ...))
>
> From: Alexandre Oliva <[EMAIL PROTECTED]>
>> On Mar 28, 2005, Paul Schlie <[EMAIL PROTECTED]> wrote:
>
>> More specifically, if GCC enabled set to optionally specify multiple targets
>> for a single rtl source expression, i.e.:
>
>> (set ((reg:xx %0) (reg CC) ...) (some-expression:xx ...))
>
On Mar 28, 2005, Paul Schlie <[EMAIL PROTECTED]> wrote:
> More specifically, if GCC enabled set to optionally specify multiple targets
> for a single rtl source expression, i.e.:
> (set ((reg:xx %0) (reg CC) ...) (some-expression:xx ...))
There's always (set (parallel (...)) (some-expression))
Sorry, I dropped the ball on this one.
On Mar 24, 2005, Ian Lance Taylor wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> I realize the sequence construct is already taken for delayed
>> branches, but that's only in the outermost insn pattern. We could
>> overload the meaning, or just en
> Richard Henderson
>> Ian Lance Taylor wrote:
>> OK, here is a different approach toward eliminating cc0, based on a
>> combination of my earlier proposal and what Alex described. I'm
>> looking for comments from anybody.
>
> One potential problem: once the NOTICE_UPDATE_CC pass is done, we
> ca
> From: Ian Lance Taylor
> Date: 29 Mar 2005 23:05:11 -0500
> Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:
> What am I missing?
If anything, to post an updated proposal spelling out the bits
below!
(I.e. nothing as long as there is always a matching
automatically generated insn; one with an a
Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:
> > 4) For each target which uses cc0:
> ...
> >4b) For insn patterns for which some alternatives clobber CC and
> >some do not, split the instruction after reload into one
> >variant which clobbers the CC and one variant which doe
I'm behind on reading mailing lists and only "skipped ahead" for
this thread. (I may have missed some related follow-ups.)
> From: Ian Lance Taylor
> Date: 24 Mar 2005 11:44:52 -0500
> 1) Modify the programs which read the .md file to look for an
>attribute named clobbercc. If such an attr
> From: Paul Koning <[EMAIL PROTECTED]>
>> "tm" == tm gccmail <[EMAIL PROTECTED]> writes:
>>> On 25 Mar 2005, Ian Lance Taylor wrote:
>>> Safe but very costly. It assumes that every processor has a cheap
>>> way to save and restore the condition codes in user mode, which is
>>> not necessarily the
> "tm" == tm gccmail <[EMAIL PROTECTED]> writes:
tm> On 25 Mar 2005, Ian Lance Taylor wrote:
>> Safe but very costly. It assumes that every processor has a cheap
>> way to save and restore the condition codes in user mode, which is
>> not necessarily the case. And it assumes that the sav
> From: Ian Lance Taylor
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>> Might this likely work? And if so, possibly be worthy of consideration to
>> enable the more efficient description and optimization of traditional cc0
>> target machines (and possibly be beneficial for other ISA's as well)?
>
On 25 Mar 2005, Ian Lance Taylor wrote:
> Paul Schlie <[EMAIL PROTECTED]> writes:
>
> > > 2) Reload requires the ability to insert arbitrary instructions
> > >between any pair of instructions. The instructions inserted by
> > >reload will load registers from memory, store registers to me
Steven Bosscher wrote:
As far as I can tell, there is no architecture requirement that p1 and
p2 must be a register pair (ie. p6,p7 or p2,p3, etc.), but that seems
to be the only form that GCC can produce.
Perhaps this was done this way to avoid insn patterns with two sets?
It was done this way bec
Paul Schlie <[EMAIL PROTECTED]> writes:
> Might this likely work? And if so, possibly be worthy of consideration to
> enable the more efficient description and optimization of traditional cc0
> target machines (and possibly be beneficial for other ISA's as well)?
It seems like it might work to m
Hi Ian, (getting back to reality) upon reviewing things further, it appears
that if GCC could relax it's single-set restriction to enable a restricted
form of multi-set instructions to be included in optimizations; then ISA's
who's instructions either implicitly set or depend on global machine stat
> From: Ian Lance Taylor
>> Paul Schlie <[EMAIL PROTECTED]>
>> (is this not feasible if the target is accurately described in rtl?)
>
> I don't know how to respond to this. I'm discussing a way to achieve
> an incremental improvement in gcc. You seem to be discussing a
> different compiler.
Paul Schlie <[EMAIL PROTECTED]> writes:
> I presume that "code" can/should be optimally generated once by initially
> optimally covering the rtl representing a basic block (with minimal cost
> in either storage, cycles or some hybrid of both); where there's then no
> need to ever subsequen
> From: Ian Lance Taylor
> I'm also not aware of processors changing as you describe, except for
> the particular special case of SIMD vector instructions. gcc can and
> does represent vector instructions as a single set.
- Understood, unfortunately hiding the multiple-set nature of instructions
BjÃrn Haase <[EMAIL PROTECTED]> writes:
> Imagine, you are having a clean md with a consistent "double set"
> representation for all the patterns that actually alter the condition code. I
> understood, that the problem for the optimization passes (e.g. combine) then
> shows up only for instruct
On Saturday 26 March 2005 04:11, Ian Lance Taylor wrote:
> I'm also not aware of processors changing as you describe,
Well, ia64 comes to mind. Take the cmp4.* instructions for example.
They are of the form "(predicate) cmp4.cmpoperator p1,p2 = cmpoperands"
where p1 and p2 are predicate registers
Paul Schlie <[EMAIL PROTECTED]> writes:
> > 1) Many of the optimizers analyze instructions by first calling
> >single_set and working with the results of that. For example,
> >combine won't work with any insn for which single_set returns NULL.
> >And single_set will normally return NU
> From: Ian Lance Taylor
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>> Thereby enabling something like:
>>
>> (insn xxx [(set (reg: A) (xxx: (reg: B) (reg: C)))
>>(set (reg: CC) (newly-set-reg: A))
>> )
>>
>> (insn branch-equal (set (pc) (if_then_else
>>
Paul Schlie <[EMAIL PROTECTED]> writes:
> Is there any convenient way to reference the newly set register by an
> instruction, as opposed to otherwise needing to redundantly re-specify
> the operation producing it's value again?
>
> Thereby enabling something like:
>
> (insn xxx [(set (reg: A) (
> From: Ian Lance Taylor
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>> Does GCC truley need to identify/treat condition state registers uniquely
>> from any other value produced as a result of a calculation?
>
> No, it doesn't. The change I am proposing removes the unique handling
> of condition
Paul Schlie <[EMAIL PROTECTED]> writes:
> Does GCC truley need to identify/treat condition state registers uniquely
> from any other value produced as a result of a calculation?
No, it doesn't. The change I am proposing removes the unique handling
of condition state registers, and treats them li
> Ian Lance Taylor writes:
> We would like to eliminate cc0 and the associated machinery from the
> compiler, because it is complicated and not supported on popular or
> modern processors. Here is a plan which I think could accomplish that
> without unreasonable effort.
I pre-apologize if this i
Ian Lance Taylor writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>> I'm not understanding why this is a separate pass, instead of
>> generating the combined instructions directly in the expander. I
>> think generic expander support for compare-and-branch instructions
>> already exists...
>
>
Zack Weinberg <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > 3) Write a new CC0 collapse pass. This pass is run immediately
> > after RTL expansion. It walks the instruction stream looking for
> > instructions which set and use CC_REG. At this point these
> > instructions will a
Ian Lance Taylor writes:
> 3) Write a new CC0 collapse pass. This pass is run immediately
> after RTL expansion. It walks the instruction stream looking for
> instructions which set and use CC_REG. At this point these
> instructions will always be adjacent. The pass combines them into
> the c
Richard Henderson <[EMAIL PROTECTED]> writes:
> Note that there's no longer any insn that *sets* cc_reg. I think
> that's a bit dangerous.
Hmmm, good point.
> One solution to this is to convert the new setter to
>
> [(set (reg 1) (plus (reg 1) (reg 2)))
>(set (reg cc_reg) (unspe
On Thu, Mar 24, 2005 at 11:44:52AM -0500, Ian Lance Taylor wrote:
> OK, here is a different approach toward eliminating cc0, based on a
> combination of my earlier proposal and what Alex described. I'm
> looking for comments from anybody.
One potential problem: once the NOTICE_UPDATE_CC pass is d
OK, here is a different approach toward eliminating cc0, based on a
combination of my earlier proposal and what Alex described. I'm
looking for comments from anybody.
1) Modify the programs which read the .md file to look for an
attribute named clobbercc. If such an attribute exists, then for
Ian Lance Taylor writes:
> Looking at your suggestion makes me realize that my suggestion is too
> complicated. It's not necessary to generate the combinatorial
> explosion at all. We can always keep cc0 setters and cc0 users in
> separate instructions. The key is to keep them from getting
> d
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Mar 23, 2005, Ian Lance Taylor wrote:
>
> > Of course, correctly modeling the effect on the condition codes
> > really means putting the information in the RTL so that it is
> > exposed to the RTL optimizers.
>
> True, but we want to avoid that b
On Mar 23, 2005, Ian Lance Taylor wrote:
> Of course, correctly modeling the effect on the condition codes
> really means putting the information in the RTL so that it is
> exposed to the RTL optimizers.
True, but we want to avoid that because of the loss of optimization
opportunities. Besides,
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> >2a) Define the clobbercc attribute to be "yes" for each insn which
> >changes the condition codes unpredictably. Typically the
> >default would be "yes", and then either clobbercc would be
> >written to use cond to select
On Mar 23, 2005, Ian Lance Taylor wrote:
>2a) Define the clobbercc attribute to be "yes" for each insn which
>changes the condition codes unpredictably. Typically the
>default would be "yes", and then either clobbercc would be
>written to use cond to select instructio
[EMAIL PROTECTED] (Richard Kenner) writes:
> 3) Write a new optimization pass enabled on targets which define
>NOTICE_UPDATE_CC. I think this pass would be run just before
>machine dependent reorg, although perhaps there is a better place
>for it. Walk through the ins
3) Write a new optimization pass enabled on targets which define
NOTICE_UPDATE_CC. I think this pass would be run just before
machine dependent reorg, although perhaps there is a better place
for it. Walk through the instructions, calling NOTICE_UPDATE_CC on
each o
39 matches
Mail list logo
