[FunctionAttrs][ArgumentPromotion][GlobalOpt] Disable some optimisations passes for naked functions
AcceptedPublic

Authored by LukeCheeseman on Feb 12 2018, 3:32 AM.

Details

Reviewers
rnk
Summary
  • Fix for bug 36078.
  • Prevent the functionattrs, function-attrs, globalopt and argpromotion passes from changing naked functions.
  • These passes can perform some alterations to the functions that should not be applied. An example is removing parameters that are seemingly not used because they are only referenced in the inline assembly. Another example is marking the function as fastcc.

Diff Detail

LukeCheeseman created this revision.Feb 12 2018, 3:32 AM
rnk accepted this revision.Feb 13 2018, 10:30 AM

lgtm

We might want to consider some kind of helper on Function that checks for optnone and naked to block these kinds of prototype-changing optimizations.

This revision is now accepted and ready to land.Feb 13 2018, 10:30 AM

This suggestion makes sense to me. However, I have been looking into optnone and naked and I'm not sure whether they apply in the same way for inter procedural optimisations after reading https://reviews.llvm.org/D1288. An example of this is as follows:

$ cat test.ll
define internal i32 @foo(i32*) #0 {
entry:
  %retval = alloca i32, align 4
  unreachable
}

attributes #0 = { optnone noinline }

$ /work/llvm/svn+release/bin/opt -deadargelim naked.ll -S
; ModuleID = 'test.ll'
source_filename = "test.ll"

; Function Attrs: noinline optnone
define internal void @foo() #0 {
entry:
  %retval = alloca i32, align 4
  unreachable
}

attributes #0 = { noinline optnone }

The argument from foo has been removed, whereas if we make the function as naked the result is different:

$ /work/llvm/svn+release/bin/opt -deadargelim naked.ll -S 
; ModuleID = 'test.ll'
source_filename = "test.ll"

; Function Attrs: naked
define internal i32 @foo(i32*) #0 {
entry:
  %retval = alloca i32, align 4
  unreachable
}

attributes #0 = { naked }

I'm not sure whether this is a bug in deadargument elimination or is the expected behavior of optnone. Reading the description of optnone I would think it was the latter but this is reading a description from 5 years ago, in which case I'm not sure we would be able to introduce such a helper. The clang documentation on optnone is not explicit as to whether the prototypes are subject to change or not.

I'd like to hear your thoughts on this.