<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">David provided one good answer. I'll
give another.<br>
<br>
The current design pushes complexity into the language frontend
for - as far as I know - no good reason. I can say from recent
experience that the corner cases around atomics are both
surprising and result in odd looking hacks in the frontend. To
say this differently, why should marking loads and stores atomic
required me to rewrite largish chunks of code around the load or
store? There's nothing "wrong" per se with that design, but why
complicate a bunch of frontends when a single IR level desugarring
pass could preform the same logic? <br>
<br>
Another answer would be that bitcasts make the IR less readable.
They consume memory. Unless handled carefully, they inhibit
optimizations. (i.e. if you forget to strip casts in a peephole
optimization) When dealing with large IR files from a language
where *every* field access is atomic "unordered", the first two
are particularly important. <br>
<br>
p.s. I'm currently operating under the assumption that there is
no *technical* reason LLVM could represent atomic loads and stores
on floating point types. If this is not true, please correct me.
<br>
<br>
Philip<br>
<br>
On 05/24/2014 03:18 PM, Filip Pizlo wrote:<br>
</div>
<blockquote
cite="mid:A018E297-8216-4FB5-91D8-5EC341CF10E8@apple.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div>What is the downside of the currently generated IR? There
ain't nothin' wrong with bitcasts, IMO. <br>
<br>
-Filip</div>
<div><br>
On May 24, 2014, at 2:17 PM, Philip Reames <<a
moz-do-not-send="true" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Looking through the documentation, I discovered that atomic
loads and stores are only supported for integer types. Can
anyone provide some background on this? Why is this true?<br>
<br>
Currently, given code:<br>
std::atomic<float> aFloat;<br>
void foo() {<br>
float f = atomic_load(&aFloat);<br>
..<br>
}<br>
<br>
Clang generates code like:<code></code><br>
%"struct.std::atomic.2" = type { float }<br>
@aFloat = global %"struct.std::atomic.2" zeroinitializer,
align 4<br>
<br>
define void @foo() {<br>
%1 = load atomic i32* bitcast (%"struct.std::atomic.2"*
@aFloat to i32*) seq_cst, align 4<br>
%2 = bitcast i32 %1 to float<br>
...<br>
}<br>
<br>
This seems less than ideal. I would expect that we might have
to desugar floats into integer & cast operations in the
backend, but why is this imposed on the frontend? <br>
<br>
More generally, is there anyone who is knowledgeable and/or
working on atomics and synchronization in LLVM? I've got a
number of questions w.r.t. semantics and have found a number
of what I believe to be missed optimizations. I'm happy to
file the later, but I'd like to talk them over with a
knowledgeable party first.<br>
<br>
Philip<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>LLVM Developers mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a></span><br>
<span><a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span><br>
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>