This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SHIFT_COUNT_TRUNCATED
> Apparently we can't define it on the x86 -- based on this comment in i386.md.
exactly..
>
> ;; On i386, the register count for a bit operation is *not* truncated,
> ;; so SHIFT_COUNT_TRUNCATED must not be defined.
>
>
> One possible alternative would be to rewrite the bit patterns to truncate
> the shift count, then define SHIFT_COUNT_TRUNCATED for the x86.
I personally think, that my idea of extending SHIFT_COUNT_TRUNCATED is better.
Other complication is, that i386 masks even HI mode shift by 31 not by 15!
This should be handled nicely by my extension. And also ports like m68k should
benefit from this. I believe, there are more ports, wich have similar weird behaviour.
>
> > So I've been looking a bit at SHIFT_COUNT_TRUNCATED feature and I think
> > it should be extended to make macro that has two parameters (code and mode)
> > code should be ASHIFT etc amd mode shoud be DImode and so on.
> I'm not sure this is completely necessary at this point. I also suspect it'll
> be difficult to get right. Remember, it's not a cost, and if you miss a case,
> then the compiler may generate incorrect code.
Thats true. But I tought, that egcs is for testing new ideas :) And I think this
should greatly extend usability of SHIFT_COUNT_TRUNCATED at many targets (at least
i386 and m68k).
> > There don't seems to be much use for SHIFT_COUNT_TRUNCATED in gcc, so it
> > should not be much work and I should do that, if it is good thing to do.
> I don't understand this statement. SHIFT_COUNT_TRUNCATED is certainly used
> and is a valueable optimization for some architectures.
I meant, that grep SHIFT_COUNT_TRUNCATED *.c returns just few results. This means,
that is should not be big job to go trought and modify them.
If SHIFT_COUNT_TRUNCATED werent valuable optimization, I would not send this email :)
>
> While I would recommend following up on this work, I would suggest doing so
> *after* we wrap up your existing changes. Otherwise the outstanding changes
Of course. This was just idea that I want implement in future. My primary goal
now is to checkin usefull parts of my patch.
I was thinking about it a bit more in cinema yesterday and I ended
up with something like simplify_masked_const. It should be in combiner or somewhere
and take as argunent RTX and constant and simplify it in way, that results will be
same just after masking by constant. It should do optimizations like changing mask+1-x
to neg x, mask-x to not x (if mask is continuous), make smaller constant ANS (to let i386.md
and others to use byte version of instruction) and so on. It should be called for shift parameters
as well as and x,const, or x,const and possibly other expressions.
Problem is, that this points to recursive implementation and when basic block
is done in some nice way, it should go trought it many times.
> just get larger and larger and more difficult to untangle.
>
> > BTW whats are the limitation of combiner. Will pattern like:
> > (set reg0
> > (ior (ashift reg1 reg2)
> > (lshiftrt reg3 (neg reg2))))
> > ever match? (there is limitation to three instruction or so, if I remember
> > correctly)
> The combiner can directly combine 3 instructions. However, the result of one
> combination can be used in a later combination, so it is possible to combine
> more than 3 instructions.
>
> As to that specific pattern -- I don't know. combine may try to canonicalize
> it in some way or another before trying to recognize it. The best way to see
> what patterns the combiner tries is to put a breakpoint in recog_for_combine
> and look at its arguments.
OK, I will try it.
>
> > so why not to make it matching something :). I've actually made constant
> > parameter version of it and it seems to match about four times in gcc and
> > kernel. Is that worthwhile? :))
> Probably not.
Agreed. Yesterday I've tried the (not version and it don't seems to match at all.
I will keep it and use it for rewriting shift:DI patterns. It is quite shame, that it
can't match.
Honza
>
> jeff
--
OK. Lets make a signature file.
+-------------------------------------------------------------------------+
| Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz |
| Czech free software foundation: http://www.freesoft.cz |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
| homepage: http://www.paru.cas.cz/~hubicka/, games koules, Xonix, fast |
| fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc. |
+-------------------------------------------------------------------------+