Page MenuHomePhabricator

Make it possible for ints/floats to return different values from getBooleanContents()
ClosedPublic

Authored by dsanders on Jul 4 2014, 2:32 AM.

Details

Summary

On MIPS32r6/MIPS64r6, floating point comparisons return 0 or -1 but integer
comparisons return 0 or 1.

Updated the various uses of getBooleanContents. Two simplifications had to be
disabled when float and int boolean contents differ:

  • ScalarizeVecRes_VSELECT except when the kind of boolean contents is trivially discoverable (i.e. when the condition of the VSELECT is a SETCC node).
  • visitVSELECT (select C, 0, 1) -> (xor C, 1). Come to think of it, this one could test for the common case of 'C' being a SETCC too.

Preserved existing behaviour for all other targets and updated the affected
MIPS32r6/MIPS64r6 tests. This also fixes the pi benchmark where the 'low'
variable was counting in the wrong direction because it thought it could simply
add the result of the comparison.

Diff Detail

Event Timeline

dsanders updated this revision to Diff 11084.Jul 4 2014, 2:32 AM
dsanders retitled this revision from to Make it possible for ints/floats to return different values from getBooleanContents().
dsanders updated this object.
dsanders edited the test plan for this revision. (Show Details)
dsanders added a subscriber: Unknown Object (MLST).
hfinkel added inline comments.
include/llvm/Target/TargetLowering.h
289

Please remove this (we don't need the OLD version any more).

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
4528

I'm missing something here... why not?

lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
265

Again, please explain.

dsanders added inline comments.Jul 8 2014, 12:45 PM
include/llvm/Target/TargetLowering.h
289

Ok.

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
4528

We can't tell whether we have an integer-based boolean or a floating-point-based boolean unless we can find the SETCC that produced it and inspect its operands. This is fairly easy if C is the SETCC node, but it can potentially be undiscoverable (or not reasonably discoverable). For example, it could be in another basic block or it could require searching a complicated expression.

lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
265

It's the same reason as the other one but here I attempt to cover the most likely case where Cond is a SETCC.

hfinkel added inline comments.Jul 8 2014, 1:17 PM
include/llvm/Target/TargetLowering.h
978

I would really like to do this without causing churn to all of the targets (and causing pain for all out-of-tree targets). How about we do this:

void setBooleanContents(BooleanContent Ty) { BooleanContents = Ty; BooleanFloatContents = Ty; }

void setBooleanContents(BooleanContent Ty, BooleanContent FTy) { BooleanContents = Ty; BooleanFloatContents = FTy; }

do that the current target code will continue to do the right thing.

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
4528

Okay, this is reasonable. Please make the source-code comment as informative as your reply :-)

lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
265

Please make the comment reference the comment above (in DAGCombiner::visitSELECT) for an explanation.

dsanders updated this revision to Diff 11214.Jul 9 2014, 12:29 PM

Removed getBooleanContentsOLD().

Explained the two difficult cases when integer boolean contents differ from floating point boolean contents.
I was a bit concerned about people calling setBooleanContents() after setBooleanFloatContents() so I've
noted that setBooleanContents() affects both in the comments.

Removed the need to update all (including out-of-tree) targets.

dsanders added inline comments.Jul 9 2014, 12:31 PM
include/llvm/Target/TargetLowering.h
978

That makes sense to me. I've made this change in the updated patch. I've also added a comment that should ensure that people call setBooleanFloatContents() after setBooleanContents().

Assuming you take my suggestion regarding setBooleanContents (or otherwise make it so that the function-call order does not matter), LGTM. Thanks!

include/llvm/Target/TargetLowering.h
972

I'd really prefer that you do this as I suggested:
void setBooleanContents(BooleanContent Ty) { BooleanContents = Ty; BooleanFloatContents = Ty; }

void setBooleanContents(BooleanContent Ty, BooleanContent FTy) { BooleanContents = Ty; BooleanFloatContents = FTy; }

The reason is that, as you've implemented it, the order in which you call setBooleanContents and setBooleanFloatContents matters, and I think that will prove confusing.

  • Original Message -----

From: "Daniel Sanders" <daniel.sanders@imgtec.com>
To: "daniel sanders" <daniel.sanders@imgtec.com>
Cc: hfinkel@anl.gov, "justin holewinski" <justin.holewinski@gmail.com>, mcrosier@codeaurora.org,
llvm-commits@cs.uiuc.edu
Sent: Wednesday, July 9, 2014 2:31:53 PM
Subject: Re: [PATCH] Make it possible for ints/floats to return different values from getBooleanContents()

================
Comment at: include/llvm/Target/TargetLowering.h:960
@@ +959,3 @@
+ /// value from i1 to a wider type. See getBooleanContents.
+ void setBooleanFloatContents(BooleanContent Ty) {
BooleanFloatContents = Ty; }
+


hfinkel@anl.gov wrote:
> I would really like to do this without causing churn to all of the
> targets (and causing pain for all out-of-tree targets). How about
> we do this:
>
> void setBooleanContents(BooleanContent Ty) { BooleanContents = Ty;
> BooleanFloatContents = Ty; }
>
> void setBooleanContents(BooleanContent Ty, BooleanContent FTy) {
> BooleanContents = Ty; BooleanFloatContents = FTy; }
>
> do that the current target code will continue to do the right
> thing.
That makes sense to me. I've made this change in the updated patch.
I've also added a comment that should ensure that people call
setBooleanFloatContents() after setBooleanContents().

Now you see I was so speedy with my review, that I submitted it before I saw this reply ;) -- I stand by my preference, however. I think that, even with a comment, someone will manage to incorrectly order these as they refactor code.

Thanks again,
Hal

http://reviews.llvm.org/D4389

dsanders added inline comments.Jul 9 2014, 1:04 PM
include/llvm/Target/TargetLowering.h
972

Sorry, I'm trying to do a couple things in parallel at the moment and I didn't notice that it was an overloaded function. I agree that the overloaded function approach is better because it's harder to make mistakes. I'll do another update to switch to your suggestion.

dsanders updated this revision to Diff 11222.Jul 9 2014, 2:24 PM

Correctly implement Hal's suggestion.

LGTM. Thanks!

dsanders accepted this revision.Jul 10 2014, 3:25 AM
dsanders added a reviewer: dsanders.
This revision is now accepted and ready to land.Jul 10 2014, 3:25 AM
dsanders closed this revision.Jul 10 2014, 3:26 AM