[LLVMdev] questions about ARM EABI attributes

Akira Hatanaka ahatanak at gmail.com
Thu Dec 18 17:37:53 PST 2014


ARM backend emits different eabi build attributes based on the ISA variant
the target supports or whether certain fast-math options are passed on the
command line. For example, these are the attributes that have different
values depending on whether -ffast-math is passed to clang:

$ clang -target armv7-linux-gnueabi -ffast-math (with -ffast-math)

.eabi_attribute 20, 2 @ Tag_ABI_FP_denormal
.eabi_attribute 23, 1 @ Tag_ABI_FP_number_model

$ clang -target armv7-linux-gnueabi (without -ffast-math)

.eabi_attribute 20, 1 @ Tag_ABI_FP_denormal
.eabi_attribute 21, 1 @ Tag_ABI_FP_exceptions
.eabi_attribute 23, 3 @ Tag_ABI_FP_number_model

Suppose there are two functions in a module which have different sets of
function attributes. One function has attributes for "-ffast-math" (foo1)
and the other (foo0) has attributes for "-fno-fast-math". In that case,
which set of eabi attributes should ARMAsmPrinter::emitAttributes emit?
ARMAsmPrinter::emitAttributes is called once at the start of a file (not
once per every function), so I assume it has to merge those attributes
which have different values or reject the IR if it discovers
incompatibilities.

define double @foo0(double %a) #0 {
entry:
  %add = fadd double %a, 1.000000e+00
  ret double %add
}

define double @foo1(double %a) #1 {
entry:
  %add = fadd fast double %a, 2.000000e+00
  ret double %add
}

attributes #0 = { nounwind readnone "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"stack-protector-buffer-size"="8" "unsafe-fp-math"="false"
"use-soft-float"="false" }

attributes #1 = { nounwind readnone "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="true" "no-nans-fp-math"="true"
"stack-protector-buffer-size"="8" "unsafe-fp-math"="true"
"use-soft-float"="false" }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/3fa06a5b/attachment.html>


More information about the llvm-dev mailing list