<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 15, 2018 at 11:21 AM Krzysztof Parzyszek <<a href="mailto:kparzysz@codeaurora.org">kparzysz@codeaurora.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hexagon has a very few restrictions on what will cause loss of a <br>
reservation: those are stores to the same address (a 64-bit granule) or <br>
any sort of exception/interrupt/system call. Other than that the <br>
reservation should stay. The architecture doesn't explicitly guarantee <br>
that though, but in the absence of the elements listed above, a program <br>
with LL/SC can be expected to make progress.<br>
<br>
Consequently, the best way for us to handle LL/SC would be to expand <br>
them early and let them be optimized as any other code. The usual <br>
optimization restrictions should be sufficient to prevent introduction <br>
of factors causing a loss of reservation.<br>
<br>
With the constraints on LL/SC varying wildly between architectures, <br>
maybe we should have several options available for different targets?<br></blockquote><div><br></div><div>The constraints on LL/SC don't seem to vary that wildly between architectures (except Hexagon, I guess!) -- sure, the exact details are different, but they all (the others) have some set of requirements on the structure of their loop which are not generally possible guarantee in a high level abstract representation. Given that, the details of the requirements aren't particularly relevant, they just need to be properly adhered to when writing the target-specific code to generate the machine instructions for the ll/sc loop.</div><div><br></div><div>I'm a bit skeptical that Hexagon is truly different in this regards than all the other architectures. But, that said, I don't think it'd be at all problematic to keep the IR-level lowering code around for Hexagon to continue to use, even if we do migrate everything else away.</div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">We definitely need to introduce new options alongside the current options to start with, anyways -- at the very least simply to allow migrating each architecture separately.</span><br class="gmail-Apple-interchange-newline"></div></div></div>