[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