This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263

--- Comment #6 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2011-06-27 05:14:36 UTC ---
(In reply to comment #5)
> Anyway, why not just add all the currently known-to-work cases? What are your
> concerns regarding that? I can imagine that it is a maintenance burden to keep
> all those definitions and special cases in the MD up-to-date (bit rot etc). Do
> you have anything other than that in mind? 

Yep, maintenance burden but I don't mean ack/nak for anything.
If it's enough fruitful, we should take that route.  When it
gives 5% improvement in the usual working set like as CSiBE,
hundreds lines would be OK, but if it's ~0.5% or less, it doesn't
look worth to add many patterns for that.

> Isn't there a way to tell the combine pass not to do so, but instead first look
> deeper at what is in the MD?

I don't know how to do it cleanly.

> I guess this might generate wrong code for e.g. "if (x & -2)". When x has any
> bits[31:1] set this must return true. The code after the peephole optimization
> will look only at the lower 8 bits and would possibly return false for x =
> 0xFF000000, which is wrong. So it should be satisfies_constraint_K08 only,
> shouldn't it?

You are right.  That peephole was simply 'something like this'.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]