On August 2, 2016 5:21:34 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote: >On 08/01/2016 05:31 PM, Segher Boessenkool wrote: >> Hi, >> >> On Mon, Aug 01, 2016 at 06:52:54PM +0000, Bernd Edlinger wrote: >>> On 08/01/16 19:54, Jeff Law wrote: >>>> Looks like you've probably nailed it. It'll be interesting see if >>>> there's any fallout (though our RTL optimizer testing is pretty >weak, so >>>> even if there were, I doubt we'd catch it). >>> >>> If there is, it will probably a performance regression... >> >> I tested building Linux with and without the patch, on many archs. >> The few that show differences are: >> >> alpha 6148872 6148776 >> ia64 16946958 16946670 >> s390 12345770 12345850 >> tile 12016086 12016070 >> >> (left before, right after; arm and aarch64 did not build, kernel >problems). >> >> So all except s390 generate smaller code even. >They're all deep enough in the noise that I wouldn't care either way >:-) > >> >>> However I think there are more paradoxical subregs generated all >over, >>> but the aarch64 insv code pattern did trigger more hidden bugs than >>> any other port. It is certainly unfortunate that the major source >>> of paradoxical subreg is in a target-dependent code path :( >> >> It is certainly unfortunate that paradoxical subregs exist at all! >:-) >Yea. It probably seemed like a good idea 25-30 years ago, but I always > >cringe when I see them being used. Yea it gives the compiler some more > >freedom, but more often than not I think we'd be better off with real >extensions.
But we love to exploit undefined behavior elsewhere, too. Now the init-regs pass comes to my mind again (papering over issues elsewhere).. Richard. >jeff