This is an archive of the discontinued LLVM Phabricator instance.

[EarlyCSE] Simplify target intrinsic support
AbandonedPublic

Authored by reames on Dec 17 2015, 10:39 AM.

Details

Summary

This change unwinds some complexity from the target intrinsic support. Specifically, it removes the idea of an 'ExpectedType'. While we do need to check the type of the returned value (or insert a bitcast), the amount of code involved in the original implementation was a bit excessive. Note that this version may end up doing slightly more work for target intrinsics (due to the lack of an early bail), but tuning for this rare case at the cost of extra complexity seems questionable.

This change also sets us up for a possible followup enhancement to EarlyCSE. Today, we only consider exact SSA equality in the aliasing decisions made by EarlyCSE. We could potentially extend this by stripping bitcasts off the pointer operands and bitcasting the results if needed. Note that this will be necessary once we get typeless/opaque pointers plumbed through everywhere anyways.

Let me ask a basic question. *Why* do we need these target intrinsics at all? Additionally, if we need them, why can't they be expressed as struct stores since that appears to what they represent? Finally, why did we decide to put these in EarlyCSE instead of GVN? (For context, the original review thread is here: http://reviews.llvm.org/D7121)

Diff Detail

Event Timeline

reames updated this revision to Diff 43153.Dec 17 2015, 10:39 AM
reames retitled this revision from to [EarlyCSE] Simplify target intrinsic support.
reames updated this object.
reames added reviewers: hfinkel, aadg, ssijaric, pete.
reames added a subscriber: llvm-commits.
ssijaric edited edge metadata.Dec 17 2015, 11:54 AM

Hi Philip,

The intrinsics that were initially commoned in the original patch were AArch64 intrinsics that we generate with Polly. These were strided loads and stores, for which there was no equivalent LLVM IR at the time. The reason for commoning them them in EarlyCSE instead of GVN was that EarlyCSE was able to common the scalar version - it was mostly to keep it consistent that way. We still have one case for which we need GVN to common intrinsics.

Can we incorporate the LoadSite and StoreSite changes that you suggested, after this patch is merged? These are under http://reviews.llvm.org/D8313.

Thanks,
Sanjin

hfinkel edited edge metadata.Feb 2 2016, 3:49 PM

Finally, why did we decide to put these in EarlyCSE instead of GVN?

The eventual goal is still consistency between EarlyCSE and GVN here. Now that MemorySSA is arriving and our GVN will be rewritten, we'll have an opportunity to get convergence.

Additionally, if we need them, why can't they be expressed as struct stores since that appears to what they represent?

In general, I don't think that stores of structures is a good model here. They're swizzled stores (some permutation, xoring, etc. of the data is applied).

This change unwinds some complexity from the target intrinsic support. Specifically, it removes the idea of an 'ExpectedType'. While we do need to check the type of the returned value (or insert a bitcast), the amount of code involved in the original implementation was a bit excessive. Note that this version may end up doing slightly more work for target intrinsics (due to the lack of an early bail), but tuning for this rare case at the cost of extra complexity seems questionable.

The code being removed here does not seem excessive ;) -- I don't see the benefit of removing the 'ExpectedType' parameter. It will cause us to speculatively create new IR instructions. This is not really a matter of tuning, consensus seems to be that we avoid speculatively creating IR instructions whenever possible. Am I missing something?

reames abandoned this revision.Apr 25 2017, 8:38 PM