<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/17/2015 12:13 AM, deadal nix via
llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CANGV3T1BkkP8fER0jMcR7Sq6WL9GEQoO9z6WbX=Qbo-5b+D1QQ@mail.gmail.com"
type="cite">2015-08-16 23:21 GMT-07:00 David Majnemer <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class=""></span>
<div>Because a solution which doesn't generalize is not a
very powerful solution. What happens when somebody says
that they want to use atomics + large aggregate loads
and stores? Give them yet another, different answer?
That would mean our earlier, less general answer,
approach was either a bandaid (bad) or the new answer
requires a parallel code path in their frontend (worse).</div>
<span class="">
<div> </div>
</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>It is expected from atomics/volatile to work differently.
That is the whole point of them.<br>
<br>
</div>
<div>A lot of optimization in InstCombine plain ignore
atomic/volatile load/store. That is expected.</div>
</blockquote>
I agree with this particular point. If we limited the optimizer to
treating all load and stores the same, we'd have a much weaker
optimizer. Treating atomic vs non-atomic FCAs differently from an
optimization standpoint seems potentially reasonable. I would not
want to treat them differently from a correctness/lowering strategy
standpoint. (i.e. both the input and output from instcombine need
to trigger somewhat sane results from the backend.)<br>
<br>
Philip<br>
</body>
</html>