This is the mail archive of the gcc-patches@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]

Re: [PATCH] Use gen_lowpart_or_truncate in simplify_shift_const_1


Roger Sayle writes:
> I suspect that this distinction is not intentional, but more likely
> a side-effect of missing optimizations in simplify_gen_unary_1.
> It would reduce my concerns about !TRULY_NOOP_TRUNCATION changes,
> if someone could check that TRUNCATEs were (almost?) always converted
> to SUBREGs on TRULY_NOOP_TRUNCATION targets.  This would allow us to
> safely use TRUNCATEs in the middle-end, but guarantee we don't adversely
> affect performance for the common case/targets.

I can try that.  On x86 I will just replace the gen_lowpart calls with
calls to gen_lowpart_or_truncate and change gen_lowpart_or_truncate to
use the new idiom for narrowing conversions and see what happens.

Another potential problem with the new idiom has occurred to me this
morning.  What will happen if TRULY_NOOP_TRUNCATION targets expand
TRUNCATEs.  We would turn them into SUBREGs after which the original
pattern would no longer match.

simplify_unary_operation_1 <TRUNCATE> ensures that for the most
widespread usage of TRUNCATEs so far (*mul_highpart patterns) we don't
turn TRUNCATEs into SUBREGs.  This looks like a hack to me and we
might want settle this issue before adopting the new idiom.

> Beware of infering RTL semantics from the transformations that we
> perform :-)

I just consulted the precedents :).

Adam


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