[LLVMbugs] [Bug 9344] New: ARM sub-architecture support
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Mon Feb 28 05:14:34 PST 2011
http://llvm.org/bugs/show_bug.cgi?id=9344
Summary: ARM sub-architecture support
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
AssignedTo: unassignedbugs at nondot.org
ReportedBy: rengolin at gmail.com
CC: llvmbugs at cs.uiuc.edu
When defining build attributes or codegen options for ARM, we need to know what
architecture, sub-architecture (including the default options) but also what
options the user has overriden.
Currently, there are some string comparison of the cpu name to "cortex-a8",
which is clearly broken (what about a9?). There is also a method "isCortexA8()"
which suffers from the same problem.
Some options, like Advanced_SIMD build attribute, has no way of knowing if it
has to emit the not-allowed option or just leave it blank, as there is no way
of differentiating if the user has chosen a target without NEON or has
explicitly disabled NEON on a target with it.
I propose we should build an infrastructure that will return possible AND
implemented abilities in a defined sub-target.
For instance, Cortex-A9 CAN-HAVE NEON but the Tegra2 board doesn't, so the
result of the two calls below would be:
subtarget->hasNEON() : false
subtarget->supportsNEON() : true
or some other more refined architecture like:
subtarget->hasNEON() : false
subtarget->supported->hasNEON() : true
With supported being a subtarget type and always being filled with the default
parameters, while the subtarget itself can be modified with the command-line
parameters.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list