>> >> In expr.c, with TER you can detect such patterns, in this case when >> expanding the comparison, but perhaps we want a *.pd file that would have >> rules that would be only GIMPLE and only enabled in a special pass right >> before (or very close to) expansion, that would perform such instruction >> selection. > > > Wild idea, but could it be considered to have target-specific > match.pd files that can be included in the main match.pd? > That way, targets would get the benefit of getting > the target-specific folding they benefit from at the very beginning > of compilation without stepping on other targets toes.
The downside is preventing duplication, potentially reducing "generic" improvements and a maintenance headache for gimple optimizers. regards Ramana > > Kyrill > > >> >>> Ok, I am not familiar with sparc64. The constant is just a 1 >>> in the sign bit orred with a continuous string of ones. >>> That's usually cheap on aarch64 but may not be so on other targets. >> >> It has been a long time since I've done anything on sparc64, but you can >> e.g. have a look at config/sparc/sparc.c (sparc_emit_set_const64) >> to clearly see that not all constants are equal cost, some are much more >> expensive. Seems sparc_rtx_cost does not model this accurrately, but that >> is a backend bug, so shouldn't affect the generic decisions. Sparc does >> not >> have a moddi3 pattern, so your transformation might still be a win there, >> except for -Os where it would be very bad code size pessimization. >> >> All I want to say is that on GIMPLE we usually perform transformations >> where >> simpler (fewer operations) is considered better, and for the same number >> of >> operations where one sequence might be better on one target and another on >> another target, supposedly we want some other infrastructure. >> >> Jakub >> >
