LLVM mangler doesn't mangle AVX instructions

The LLVM mangler does not currently transform AVX instructions on x86-64 platforms, due to a missing #include. Also, it is significantly more complicated than necessary, due to the file into sections (not needed anymore), and is sensitive to the details of the whitespace in the assembly.

I have attached a modified mangler that I believe to be simpler and more robust. I have not tested it, though, as I do not have a recent enough version of LLVM on my machine.

I am marking this as `Runtime crash' because that is what would happen if the unchanged AVX instructions made their way into the executable.

Trac metadata

Trac field	Value
Version	7.11
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (LLVM)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added LLVM backend Tbug Trac import labels

Attached file LlvmMangler.hs ($1086).

New LLVM mangler

In fact the CPP around the AVX rewriting stuff was broken anyways (should have been #ifdef REWRITE_AVX not #if REWRITE_AVX) so even if x86_64_TARGET_ARCH was set, the result would have been a CPP error. It looks like this never actually worked.

Makes me wonder if we even need the AVX rewriting nowadays; or maybe we've told LLVM not to use these instructions, and could now allow it to; or maybe we can tell it not to assume the stack is 32-byte aligned.

Your rewrite looks generally sensible, though I haven't examined it closely. cc'ing Ben since I think he did the conversion to use prefix data for tables-next-to-code.

Paging bgamari.

Ahh, sorry, this somehow slipped through the cracks. I'll have a look first thing tomorrow.

I've opened D1034 with this. dobenour, you should feel free to commandeer this Diff so it has the proper attribution. I'll review the patch itself on Phab.

Indeed it would be nice if we could eliminate this mangling altogether. I'll add it to my queue although that shouldn't discourage others from looking at this.

Trac metadata

Trac field	Value
Differential revisions	→ D1034

mentioned in commit 600b153a

changed milestone to %8.0.1

Milestone renamed

What is the status here. Fixed?

Edit: answering my own question. No, see ticket:10394#comment:101775:

Indeed it would be nice if we could eliminate this mangling altogether.

closed

This particular issue can be closed.

The more general problem of the LLVM mangler we'll track as #11138.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added runtime crash label

added Pnormal label