[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