<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 28/03/12 20:53, Richard Osborne wrote:
<blockquote cite="mid:6B7D654E-479D-4104-9D48-DE67E144BEAB@xmos.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>However after a bit more thought I'm worried about another
problem. If we return <span style="color: rgb(0, 0, 0);
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; background-color: rgb(255, 255, 255);">OnlyAccessesArgumentPointees
then there will be no dependence between two inline asm calls
with the "sideeffect" keyword without the "memory" clobber if
we can prove that none of the arguments of the first inline
asm call can alias any of the arguments of the second inline
asm call. This would allow us to motion one of the asm calls
around the other. </span><span style="color: rgb(0, 0, 0);
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; background-color: rgb(255, 255, 255);">However
based on the description of volatile asm I'm not sure if this
would be valid. This makes me think I should look at modifying
the getModRefInfo(ImmutableCallSite CS, const Location
&Loc) method instead.</span></div>
<div><span style="color: rgb(0, 0, 0); font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
background-color: rgb(255, 255, 255);"></span>_______________________________________________<br>
</div>
<pre wrap="">llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
The updated patch fixes this problem. It introduces the concept of
"InvisibleMemory" - memory which can never be accessed via a load or
store via pointer. This allows us to reason about instructions /
calls with side effects that would prevent (for example) reordering
the calls around each other but shouldn't inhibit optimizations of
loads / stores.<br>
<br>
Does this seem like a reasonable approach?<br>
<pre class="moz-signature" cols="72">--
Richard Osborne | XMOS
<a class="moz-txt-link-freetext" href="http://www.xmos.com">http://www.xmos.com</a>
</pre>
</body>
</html>