[PATCH] rs6000: inefficient 64-bit constant generation for consecutive 1-bits
Segher Boessenkool
segher@kernel.crashing.org
Tue Sep 15 14:01:36 GMT 2020
Hi!
On Tue, Sep 15, 2020 at 02:23:16PM +0930, Alan Modra wrote:
> On Thu, Sep 10, 2020 at 04:58:03PM -0500, Peter Bergner via Gcc-patches wrote:
> > +unsigned long
> > +test0 (void)
> > +{
> > + return 0x00ffffffffffff00UL;
> > +}
> > +
> > +unsigned long
> > +test1 (void)
> > +{
> > + return 0x00ffffffff000000UL;
> > +}
> > +
> > +unsigned long
> > +test2 (void)
> > +{
> > + return 0x00ffff0000000000UL;
> > +}
> > +
> > +unsigned long
> > +test3 (void)
> > +{
> > + return 0xffffff0000000000UL;
> > +}
> > +
> > +unsigned long
> > +test4 (void)
> > +{
> > + return 0xffffff000000ffffUL;
> > +}
> > +
> > +unsigned long
> > +test5 (void)
> > +{
> > + return 0x0000010000000000UL;
> > +}
> > +
> > +/* { dg-final { scan-assembler "rldic r?\[0-9\]+,r?\[0-9\]+,8,8" } } */
> > +/* { dg-final { scan-assembler "rldic r?\[0-9\]+,r?\[0-9\]+,24,8" } } */
> > +/* { dg-final { scan-assembler "rldic r?\[0-9\]+,r?\[0-9\]+,40,8" } } */
> > +/* { dg-final { scan-assembler "rldic r?\[0-9\]+,r?\[0-9\]+,40,48" } } */
> > +/* { dg-final { scan-assembler "rldic r?\[0-9\]+,r?\[0-9\]+,40,23" } } */
>
> Just a comment, I don't really see too much reason to change anything,
> but scan-assembler tests can be a maintenance pain in cases like these
> where there are multiple ways to generate a constant in two
> instructions. For example,
>
> test3:
> li 3,-1
> rldicr 3,3,0,23
> blr
> and
>
> test5:
> li 3,16384
> rotldi 3,3,26
> blr
>
> would be two valid possibilities for test3 and test5 that don't use
> rldic. Ideally the test would verify the actual values generated by
> the test functions and count instructions.
Well, the point of the test is to verify we get the expected code for
this?
Maybe we should just count insns here? But that would be a different
test. I'm a bit worried about how often the one-bit thing will do
something unexpected, but the rest should be fine and not cause churn.
Segher
More information about the Gcc-patches
mailing list