[PATCH] Implement getNoopForMachoTarget for SPARC

[Eric Christopher]

>
>
> >
> > Also it probably shouldn't be returning subsections via symbols as well.
> >
> > Anyhow, let's solve the original problem better :)
>
> Soo... any ideas here?
>

Sure. Looking through the code a bit...

A) Rename getNoopForMacho to just getNoop. I don't think any of the nop
codes are mach-o specific.
B) The subsections via symbols thing there is important, as far as I know
only darwin will actually fail if a function is empty (and that's only
because the linker will just coalesce the two symbols and ditch one iirc).
C) Reading the patch that put in RequiresNoop I think it's still an "only
darwin" thing.

At the very least gcc doesn't have a problem emitting:

dzur:~/tmp> cat foo.c
void f(void) {
  __builtin_unreachable();
}

dzur:~/tmp> gcc -O3 -S -o - -fomit-frame-pointer foo.c
.file "foo.c"
.section .text.unlikely,"ax", at progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl f
.type f, @function
f:
.LFB0:
.cfi_startproc
.cfi_endproc
.LFE0:
.size f, .-f
.section .text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident "GCC: (GNU) 4.9.0 20140310 (experimental)"
.section .note.GNU-stack,"", at progbits

and I think the FDE appears valid there. Which means that r108568 should be
darwin only.

So, ultimately, I think the correct fix is to make sure that HasAnyRealCode
returns false for the testcases that r108568 was designed to work around,
then remove the RequiresNoop bit from the conditional that was leading you
down this path.

How does this sound?

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140910/db930810/attachment.html>