This is an archive of the discontinued LLVM Phabricator instance.

[AST] Remove notion of volatile from alias sets
ClosedPublic

Authored by reames on Aug 15 2018, 9:27 AM.

Details

Summary

Volatility is not an aliasing property. We used to model volatile as if it had extremely conservative aliasing implications, but that hasn't been true for several years now. So, it doesn't make sense to be in AliasSet.

It also turns out the code is entirely a noop. Outside of the AST code to update it, there was only one user: load store promotion in LICM. L/S promotion doesn't need the check since it walks all the users of the address anyway. It already checks each load or store via !isUnordered which causes us to bail for volatile accesses. (Look at the lines immediately following the two remove asserts.)

There is the possibility of some small compile time impact here, but the only case which will get noticeably slower is a loop with a large number of loads and stores to the same address where only the last one we inspect is volatile. This is sufficiently rare it's not worth optimizing for..

Diff Detail

Event Timeline

reames created this revision.Aug 15 2018, 9:27 AM
hiraditya added a subscriber: hiraditya.

There was discussion sometime back, might be worth looking at: https://groups.google.com/forum/#!topic/llvm-dev/uLvitfqEd_g

There was discussion sometime back, might be worth looking at: https://groups.google.com/forum/#!topic/llvm-dev/uLvitfqEd_g

I'm missing why this is relevant? It happens to involve a volatile access as an AliasSet, but seems otherwise unrelated. From what I can tell, the "volatile implies mod" thing hasn't been true for years.

mkazantsev requested changes to this revision.Aug 16 2018, 9:27 PM
mkazantsev added inline comments.
test/Transforms/LICM/hoisting.ll
153

Please add CHECK-LABEL: Out after the load, otherwise we cannot be sure that we didn't sink.

test/Transforms/LICM/scalar-promote.ll
80

Two concerns here:

  1. If you want to make sure that we don't sink, please add CHECK-LABEL: Out after the check on store.
  2. In this particular case, it would be correct to either hoist or sink, just because we *never* go to the 2nd iteration and this code is in fact linear. The optimizer could've recognized this pattern and sunk or hoisted the instruction, and it would not be a bug. Do you mind making a similar test but with a different loop exit condition in which that would be incorrect?
This revision now requires changes to proceed.Aug 16 2018, 9:27 PM
reames updated this revision to Diff 161626.Aug 20 2018, 5:45 PM

Rebase.

Max, I landed the changes for the test separately. I applied your check-label request, but not one about single iteration loops since the test file is filed with such. Anyone who wants to specialize single iteration loops has some work to do later anyways, so I didn't see any value.

This revision is now accepted and ready to land.Aug 21 2018, 6:10 AM
reames closed this revision.Aug 21 2018, 11:38 AM

Committed as:
Author: reames
Date: Tue Aug 21 10:59:11 2018
New Revision: 340312