Skip to content
  1. Jun 12, 2015
  2. Jun 06, 2015
  3. Jun 05, 2015
  4. Jun 04, 2015
    • Artyom Skrobov's avatar
      Simplify ARMTargetParser::getArchSynonym · 85aebc8c
      Artyom Skrobov authored
      Summary:
      1) The only caller, ARMTargetParser::parseArch, uses the results for an "endswith" test; so, including the "arm" prefix into the result is unnecessary.
      2) Most ARMTargetParser::parseArch callers pass it the output from ARMTargetParser::getCanonicalArchName; so, make this behaviour the default. Then, including the "arm" prefix into the cases is unnecessary.
      
      Reviewers: rengolin
      
      Reviewed By: rengolin
      
      Subscribers: llvm-commits
      
      Differential Revision: http://reviews.llvm.org/D10249
      
      llvm-svn: 239099
      85aebc8c
  5. May 30, 2015
    • Renato Golin's avatar
      [ARMTargetParser] Move IAS arch ext parser. NFC · 230d2983
      Renato Golin authored
      The plan was to move the whole table into the already existing ArchExtNames
      but some fields depend on a table-generated file, and we don't yet have this
      feature in the generic lib/Support side.
      
      Once the minimum target-specific table-generated files are available in a
      generic fashion to these libraries, we'll have to keep it in the ASM parser.
      
      llvm-svn: 238651
      230d2983
  6. May 28, 2015
  7. May 27, 2015
    • Renato Golin's avatar
      ARMTargetParser: Normalising build attributes · f7c0d5f2
      Renato Golin authored
      Now that most of the methods in Clang and LLVM that were parsing arch/cpu/fpu
      strings are using ARMTargetParser, it's time to make it a bit more conforming
      with what the ABI says.
      
      This commit adds some clarification on what build attributes are accepted and
      which are "non-standard". It also makes clear that the "defaultCPU" and
      "defaultArch" methods were really just build attribute getters.
      
      It also diverges from GCC's behaviour to say that armv2/armv3 are really an
      ARMv4 in the build attributes, when the ABI has a clear state for that: Pre-v4.
      
      llvm-svn: 238344
      f7c0d5f2
  8. May 22, 2015
    • Renato Golin's avatar
      Reinforce ARMTargetParser::getCanonicalArchName validation · ebdd12cb
      Renato Golin authored
      Before, getCanonicalArchName was relying on parseArch() to validate the arch
      name, which was a problem when other methods, that also needed to call it,
      were duplicating the steps.
      
      But to dissociate getCanonicalArchName from parseArch, we needed to make
      getCanonicalArchName more robust in detecting valid arch names. It's still
      not perfect, but will do for the time being, until we merge Triple with
      TargetParser into a TargetDescription mega class.
      
      llvm-svn: 238047
      ebdd12cb
    • Renato Golin's avatar
      Adding profile and version parsers to ARMTargetParser · fadc2108
      Renato Golin authored
      This allows us to match armv6m to default to thumb, but will also be used by
      Clang's driver and remove the current incomplete copy in it.
      
      llvm-svn: 238036
      fadc2108
  9. May 21, 2015
    • Renato Golin's avatar
      Make Triple::parseARMArch use ARMTargetParser · b6b9e056
      Renato Golin authored
      Simplifying Triple::parseARMArch, leaving all the parsing to ARMTargetParser.
      
      This commit also adds AArch64 detection to ARMTargetParser canonicalization,
      and a two RedHat arch names (v{6,7}hl, meaning hard-float / little-endian).
      
      Adding enough unit tests to cover the basics. Clang checks fine.
      
      llvm-svn: 237902
      b6b9e056
  10. May 20, 2015
    • Renato Golin's avatar
      Get Triple::getARMCPUForArch() to use TargetParser · e8048f0d
      Renato Golin authored
      First ARMTargetParser FIXME, conservatively changing the way we parse CPUs
      in the back-end. Still not perfect, with a lot of special cases, but moving
      towards a more generic solution.
      
      Moving all logic to the target parser made some unwritten assumptions
      about architectures in Clang to break. I've added a lot of architectures
      required by Clang, and default to CPUs that Clang believes it should
      (and I agree).
      
      I've also added a lot of unit tests, with the correct CPU for each
      architecture, and Clang seems to be working correctly, too.
      
      It also became clear that using "unsigned ID" as the argument for the get
      methods makes it hard to know what ID, so I also changed the argument names
      to match the enum type names.
      
      llvm-svn: 237797
      e8048f0d
  11. May 12, 2015
  12. May 08, 2015
    • Renato Golin's avatar
      TargetParser: FPU/ARCH/EXT parsing refactory - NFC · f5f373fc
      Renato Golin authored
      This new class in a global context contain arch-specific knowledge in order
      to provide LLVM libraries, tools and projects with the ability to understand
      the architectures. For now, only FPU, ARCH and ARCH extensions on ARM are
      supported.
      
      Current behaviour it to parse from free-text to enum values and back, so that
      all users can share the same parser and codes. This simplifies a lot both the
      ASM/Obj streamers in the back-end (where this came from), and the front-end
      parsers for command line arguments (where this is going to be used next).
      
      The previous implementation, using .def/.h includes is deprecated due to its
      inflexibility to be built without the backend support and for being too
      cumbersome. As more architectures join this scheme, and as more features of
      such architectures are added (such as hardware features, type sizes, etc) into
      a full blown TargetDescription class, having a set of classes is the most
      sane implementation.
      
      The ultimate goal of this refactor both LLVM's and Clang's target description
      classes into one unique interface, so that we can de-duplicate and standardise
      the descriptions, as well as make it available for other front-ends, tools,
      etc.
      
      The FPU parsing for command line options in Clang has been converted to use
      this new library and a number of aliases were added for compatibility:
       * A bogus neon-vfpv3 alias (neon defaults to vfp3)
       * armv5/v6
       * {fp4/fp5}-{sp/dp}-d16
      
      Next steps:
       * Port Clang's ARCH/EXT parsing to use this library.
       * Create a TableGen back-end to generate this information.
       * Run this TableGen process regardless of which back-ends are built.
       * Expose more information and rename it to TargetDescription.
       * Continue re-factoring Clang to use as much of it as possible.
      
      llvm-svn: 236900
      f5f373fc
Loading