[llvm-commits] [PATCH] Fix PR11004: Crash in llc arm backend

[Dan Gohman]

On Sep 25, 2011, at 5:45 PM, David Meyer wrote:

> Cameron,
> 
> With regards to your comment that it is inconsiderate to break the tree intentionally, you are forgetting that this was an experimental feature that never worked outside of small test cases. Neither Clang nor llvm-gcc will generate byval on ARM, so it gets no real testing. It might be more considerate to users to just add an assert saying that ARM byval doesn't work.
> 
> I dislike the idea of selective IR support. This creates a hidden (undocumented) contract between the frontends and backends, which limits the IR that is valid. It also treats external producers of bitcode as second-class citizens, since they must effectively mimic Clang or DragonEgg to guarantee that their output will be supported. It is nicer if every backend can handle any valid bitcode (even if doing so is not terribly efficient).

LLVM IR is brimming with selective IR support.  It's a compiler IR, not an
actual virtual machine.
 
> I'll let someone else comment on whether we'd rather have a byval that inserts long chains of copies or just disable it entirely. If it is the former, your patch looks fine with the XFAIL of that test removed.
> 
> Struct passing by-value is known to be an inefficient operation. Code demanding performance will usually pass around a const pointer/reference instead if the struct is large. It is a nice performance enhancement to use memcpy, but it doesn't seem too critical. Is there a specific benchmark this affects? In any case, crashing is never the answer !

Crashing reliably is better for us than silently miscompiling spuriously, which is what
the code I reverted was doing.  Reverting it helped us find and fix a few things
accidentally still using byval on ARM much sooner than we otherwise would
have.

Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110926/97c4cd1a/attachment.html>