BitScanForwardNode: LongBits test failure

[Tom Rodriguez]

> On Nov 30, 2016, at 11:52 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 30/11/16 19:14, Tom Rodriguez wrote:
>> AArch64 seems to have it’s own version of numberOfTrailingZeros instead of using the default one.  The other uses of BitScanForwardNode are explicitly protected from 0.  That being said foldStamp should probably handle the case of 0 properly.  BitScanForwardNode is sort of x86 dependent which is why it has the weird specification.
> 
> Okay, thanks.  So, I could look at getting rid of AArch64's
> numberOfTrailingZeros, but I don't think there is anything wrong
> there.
> 
> I can see that AMD64GraphBuilderPlugins has its own version of
> numberOfTrailingZeros too; unless you are talking about something
> else.  I can't see that AArch64 does anything significantly different
> to AMD64.  If you can see that it does, I'd be grateful if you could
> point me at the code.

The only other use of BitScanForwardNode is in the Long substitution and that’s explicitly protected from 0.  The other AMD64 plugin uses a platform dependent node AMD64CountTrailingZerosNode which presumably doesn’t have the same problem with 0 as the BitScanForwardNode.  So I think AArch64 needs it own platform dependent node for this.  It would probably make sense to make BitScanForwardNode have straightforward semantics and just require the back to deal with the undefined nature 0 for the actual instruction.

tom

> 
> Thanks,
> 
> Andrew.