Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to recognise commutable binop intrinsics #46241

Closed
RKSimon opened this issue Jul 29, 2020 · 7 comments
Closed

Failure to recognise commutable binop intrinsics #46241

RKSimon opened this issue Jul 29, 2020 · 7 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla

Comments

@RKSimon
Copy link
Collaborator

RKSimon commented Jul 29, 2020

Bugzilla Link 46897
Resolution FIXED
Resolved on Sep 03, 2020 10:11
Version trunk
OS Windows NT
CC @LebedevRI,@nikic,@rotateright
Fixed by commit(s) 0965272, 2391a34

Extended Description

define <2 x i64> @​smax(<2 x i64> %a, <2 x i64> %b) {
%x = call <2 x i64> @​llvm.smax.v2i64(<2 x i64> %a, <2 x i64> %b)
%y = call <2 x i64> @​llvm.smax.v2i64(<2 x i64> %b, <2 x i64> %a)
%o = or <2 x i64> %x, %y
ret <2 x i64> %o
}
declare <2 x i64> @​llvm.smax.v2i64(<2 x i64>, <2 x i64>)

opt -O3

define <2 x i64> @​smax(<2 x i64> %a, <2 x i64> %b) {
%x = tail call <2 x i64> @​llvm.smax.v2i64(<2 x i64> %a, <2 x i64> %b)
%y = tail call <2 x i64> @​llvm.smax.v2i64(<2 x i64> %b, <2 x i64> %a)
%o = or <2 x i64> %x, %y
ret <2 x i64> %o
}

but we should be able to recognise that %x and %y are equivalent:

define <2 x i64> @​smax(<2 x i64> %a, <2 x i64> %b) {
%x = tail call <2 x i64> @​llvm.smax.v2i64(<2 x i64> %a, <2 x i64> %b)
ret <2 x i64> %x
}

@RKSimon
Copy link
Collaborator Author

RKSimon commented Jul 29, 2020

assigned to @rotateright

@rotateright
Copy link
Contributor

There are 2 parts to solving this:

  1. Add logic to EarlyCSE to recognize commutable intrinsics.
  2. Add canonicalization to InstCombine so a constant operand is always the 2nd op.

@nikic
Copy link
Contributor

nikic commented Aug 1, 2020

Weirdly, there is a Commutative property in Intrinsics.td but it seems to be getting completely ignored, as there is no corresponding attribute. Do we want to add one? It might be slightly odd in that this attribute wouldn't really be useful for anything but intrinsics.

@rotateright
Copy link
Contributor

Weirdly, there is a Commutative property in Intrinsics.td but it seems to be
getting completely ignored, as there is no corresponding attribute. Do we
want to add one? It might be slightly odd in that this attribute wouldn't
really be useful for anything but intrinsics.

It's weirder still because we have things like this:
def int_smul_fix : Intrinsic<[llvm_anyint_ty],
[LLVMMatchType<0>, LLVMMatchType<0>, llvm_i32_ty],
[IntrNoMem, IntrSpeculatable, IntrWillReturn,
Commutative, ImmArg<ArgIndex<2>>]>;

So we should assume that for an intrinsic marked "Commutative" that we always mean only the 1st 2 args.

I may be overlooking something, but I don't see any other place in the optimizer that would benefit from an attribute. Ie, we need to embed commute knowledge into transforms in instcombine anyway.

If that's correct, then I think it's not worth the effort of creating a new attribute to map the property to.

@rotateright
Copy link
Contributor

Proposal:
https://reviews.llvm.org/D86798

@rotateright
Copy link
Contributor

0965272

With some follow-ups to SLP, FastISel, GVN:

af4581e

2d3e128

e25449f

NewGVN needs more work to be on par with GVN. Not sure if anyone is planning to make that the default GVN. It's been sitting on the side for a long time.

@rotateright
Copy link
Contributor

These should be the last steps for commutative analysis for min/max:
bdd5bfd

2391a34

I opened bug 47409 to track the newgvn enhancement and bug 47410 for early-cse.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

3 participants