[llvm-dev] invariant.load metadata semantics

[Piotr Padlewski via llvm-dev]

On Aug 25, 2016 16:09, "Sanjoy Das via llvm-dev" <llvm-dev at lists.llvm.org>
wrote:

Hi Hal,

Hal Finkel via llvm-dev wrote:
> Some questions: Do we allow stores to these locations at all? Only if

I'd vote for disallowing stores to these locations, but if "stores
allowed only if the value is the same" is helpful in some situation
then I don't have specific reasons why that would be problematic.

I disagree. It's much easier to write fronted and use invariant load when
you can emit stores that store the same value.
For example with invariant.group used on vptrs optimizer can assume the 2
loads load the same vtable, even when you can write code in c++ that is
valid that store vptr after calling virtual function (like placement
new(this) with the same type).


> the value is the same? Must any change be observable to be a problem? Do

Not sure what you mean by "Must any change be observable".


> atomic loads of invariant locations really need to be atomic?

It depends on the answer to "Do we allow stores to these locations at
all?".  If we don't allow stores to these locations at all then atomic
loads are not required, since we can't have racing stores to that
location.

However, syntactically, I'd be tempted to allow invariant loads to be
atomic; and maybe have a later pass strip out the atomic bit if the
semantics we decide allow that.

-- Sanjoy

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160825/50548f41/attachment.html>