> > It would be nice to only have to write the set+set version, and do
> > some markup to say which of the clobber variants should be generated,
> > yes.
>
> define_subst should be able to do that.
The Visium port uses that (but the other way around).
--
Eric Botcazou
On Sun, Jan 18, 2015 at 05:28:39PM -0600, Segher Boessenkool wrote:
> On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> > The current cc-first order happened more of an accidental
> > opinion than an architectural decision as I vaguely recall, when
> > asking. We also have the
On Sun, Jan 18, 2015 at 04:26:27PM -0500, Hans-Peter Nilsson wrote:
> For targets where most insns set condition-codes (and that don't
> use the deprecated CC0-machinery), those insns will always be
> expressed using a parallel with (most often) two members, one
> being the "main" part of the insn
On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> The current cc-first order happened more of an accidental
> opinion than an architectural decision as I vaguely recall, when
> asking. We also have the canonical location of a *cc clobber*,
> i.e. last in a parallel. For that r
On Sat, 17 Jan 2015, Jakub Jelinek wrote:
> On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> > (Waking up an old thread with my 2 cents due to being a little
> > behind on reading...)
> >
> > On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> > > On Sat, Dec 06, 2014 at 09:28:57AM +010
On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote:
> (Waking up an old thread with my 2 cents due to being a little
> behind on reading...)
>
> On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> > On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > > That's already what it
(Waking up an old thread with my 2 cents due to being a little
behind on reading...)
On Sat, 6 Dec 2014, Jakub Jelinek wrote:
> On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > That's already what it does though, did you mean the opposite? Or did you
> > > mean to write "combine
On 12/06/2014 12:56 AM, Jakub Jelinek wrote:
> So, any other md than rx and mn10300 that uses the non-standard order?
>
Not that I'm aware of.
r~
On 12/05/14 17:58, Segher Boessenkool wrote:
On Fri, Dec 05, 2014 at 01:40:56PM -0700, Jeff Law wrote:
My first thought would be to allow both and have combine swap the order
in the vector if recog doesn't recognize the pattern. One could argue
we could go through a full permutation of ordering
On Sat, Dec 06, 2014 at 09:38:43AM +0100, Jakub Jelinek wrote:
> On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > > That's already what it does though, did you mean the opposite? Or did you
> > > mean to write "combine" instead of "compare"?
> >
> > The above should read "... that
On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote:
> > That's already what it does though, did you mean the opposite? Or did you
> > mean to write "combine" instead of "compare"?
>
> The above should read "... that existing RTX *combine* pass be updated
> ...", thanks for pointing out!
mbine canonical
>>
>> [(set-cc)
>>(operate)]
>>
>> (Because of the simplicity of the substitution in compare-elim, I prefer
>> the former as the canonical canonical.)
>> --/quote--
>
> I agree with the above.
>
>> There were some patches flowi
"officially" canonical, but it's the only
ordering that works everywhere.
Why can the compare-elim pass not simply swap the two elts of the parallel
around? The alternative is to 1) modify all machine descriptions: this
is used many hundreds of times, if not thousands, and modi
-elim from kicking in?
Yes, compare-elim doesn't work with memory references but, more radically, it
is not enabled for x86 (it is only enabled for aarch64, mn10300 and rx).
I did experiment a bit with a compare-elim pass on x86. However, as
rth said in [1]:
--quote--
If we want to use thi
mplicity of the substitution in compare-elim, I prefer
> the former as the canonical canonical.)
> --/quote--
I agree with the above.
> There were some patches flowing around [2], [3] that enhanced
> compare-elim pass for x86 needs, but the target never switched to new
> pass, mostly
elim from kicking in?
>
> Yes, compare-elim doesn't work with memory references but, more radically, it
> is not enabled for x86 (it is only enabled for aarch64, mn10300 and rx).
I did experiment a bit with a compare-elim pass on x86. However, as
rth said in [1]:
--quote--
If we want to us
16 matches
Mail list logo
