1. Dec 10, 2019
  2. Dec 09, 2019
    • Francesco Petrogalli's avatar
      [llvm][VFABI] Add more testing for LLVM internal mangling. · 2ea6ab67
      Francesco Petrogalli authored
      Summary:
      The tests cover the internal mangling for:
      
      1. Masked signatures.
      2. Scalable signatures.
      3. Masked scalable signatures with linear.
      
      Reviewers: andwar
      
      Subscribers: llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D71146
      2ea6ab67
    • Simon Tatham's avatar
      [ARM][MVE] Add intrinsics for immediate shifts. · d97b3e3e
      Simon Tatham authored
      Summary:
      This adds the family of `vshlq_n` and `vshrq_n` ACLE intrinsics, which
      shift every lane of a vector left or right by a compile-time
      immediate. They mostly work by expanding to the IR `shl`, `lshr` and
      `ashr` operations, with their second operand being a vector splat of
      the immediate.
      
      There's a fiddly special case, though. ACLE specifies that the
      immediate in `vshrq_n` can take values up to //and including// the bit
      size of the vector lane. But LLVM IR thinks that shifting right by the
      full size of the lane is UB, and feels free to replace the `lshr` with
      an `undef` half way through the optimization pipeline. Hence, to keep
      this legal in source code, I have to detect it at codegen time.
      Logical (unsigned) right shifts by the element size are handled by
      simply emitting the zero vector; arithmetic ones are converted into a
      shift of one bit less, which will always give the same output.
      
      In order to do that check, I also had to enhance the tablegen
      MveEmitter so that it can cope with converting a builtin function's
      operand into a bare integer to pass to a code-generating subfunction.
      Previously the only bare integers it knew how to handle were flags
      generated from within `arm_mve.td`.
      
      Reviewers: dmgreen, miyuki, MarkMurrayARM, ostannard
      
      Reviewed By: MarkMurrayARM
      
      Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits
      
      Tags: #clang, #llvm
      
      Differential Revision: https://reviews.llvm.org/D71065
      d97b3e3e
    • Thomas Raoux's avatar
      [ModuloSchedule] Fix data types in ModuloScheduleExpander::isLoopCarried · caabb713
      Thomas Raoux authored
      The cycle values in modulo scheduling results can be negative.
      The result of ModuloSchedule::getCycle() must be received as an int type.
      
      Patch by Masaki Arai!
      
      Differential Revision: https://reviews.llvm.org/D71122
      caabb713
    • Haojian Wu's avatar
      [clangd] Use expansion location when the ref is inside macros. · decdbc11
      Haojian Wu authored
      Summary:
      Previously, xrefs has inconsistent behavior when the reference is inside
      macro body:
      - AST-based xrefs (for main file) uses the expansion location;
      - our index uses the spelling location;
      
      This patch makes our index use file locations for references, which is
      consistent with AST-based xrefs, and kythe as well.
      
      After this patch, memory usage of static index on LLVM increases ~5%.
      
      Reviewers: ilya-biryukov
      
      Subscribers: merge_guards_bot, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
      
      Tags: #clang
      
      Differential Revision: https://reviews.llvm.org/D70480
      decdbc11
    • Michael Liao's avatar
      Fix compilation warning from GCC7. NFC. · 6626e5a0
      Michael Liao authored
      6626e5a0
    • James Henderson's avatar
      [test][llvm-cxxfilt] Add missing '-n' · 01d8bb49
      James Henderson authored
      See also e84468c1.
      01d8bb49
    • Zahira Ammarguellat's avatar
      Fix build bot fails due to the patch here: · 32c802e0
      Zahira Ammarguellat authored
      https://reviews.llvm.org/D70691
      Fixed the LIT test case. Added the REQUIRES instruction.
      32c802e0
    • Muhammad Omair Javaid's avatar
      [lldb] Remove Xfail decorators from steadily passing tests · 0964733b
      Muhammad Omair Javaid authored
      This patch removes xfail decorator from some lldb testcases which are
      passing steadily now for past few week/months on aarch64/linux buildbot.
      0964733b
    • James Henderson's avatar
      [test][llvm-cxxfilt] Fix darwin build bot · 28153905
      James Henderson authored
      When committing dba420bc, I missed that a darwin-specific change had
      been recently introduced into llvm-cxxfilt, which my change ignored and
      consequently broke the darwin build bot. This change fixes this issue as
      well as improving naming/commenting of things related to this point so
      that people are less likely to run into the same issue as I did.
      28153905
    • Sam McCall's avatar
      [clangd] Allow extract-to-function on regions that always return. · 771899e9
      Sam McCall authored
      Summary:
      We only do a trivial check whether the region always returns - it has to end
      with a return statement.
      
      Reviewers: kadircet
      
      Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
      
      Tags: #clang
      
      Differential Revision: https://reviews.llvm.org/D70569
      771899e9
    • Sam Elliott's avatar
      [RISCV] Fix mir-target-flags.ll · cb664baf
      Sam Elliott authored
      cb664baf
    • Sam McCall's avatar
      [Parser] Don't crash on MS assembly if target desc/asm parser isn't linked in. · 94603ec1
      Sam McCall authored
      Summary:
      Instead, emit a diagnostic and return an empty ASM node, as we do if the target
      is missing.
      
      Filter this diagnostic out in clangd, where it's not meaningful.
      
      Fixes https://github.com/clangd/clangd/issues/222
      
      Reviewers: kadircet
      
      Subscribers: mgorny, ilya-biryukov, jkorous, arphaman, usaxena95, cfe-commits
      
      Tags: #clang
      
      Differential Revision: https://reviews.llvm.org/D71189
      94603ec1
    • Sam Elliott's avatar
      [RISCV] Machine Operand Flag Serialization · c20930a7
      Sam Elliott authored
      Summary:
      These hooks ensure that the RISC-V backend can serialize and parse MIR
      correctly.
      
      Reviewers: jrtc27, luismarques
      
      Reviewed By: luismarques
      
      Subscribers: hiraditya, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, sameer.abuasal, apazos, llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D70666
      c20930a7
    • Djordje Todorovic's avatar
      [DebugInfo][EarlyCSE] Use the salvageDebugInfoOrMarkUndef(); NFC · 9b9e9958
      Djordje Todorovic authored
      Use the newest API.
      
      Differential Revision: https://reviews.llvm.org/D71061
      9b9e9958
    • Jeremy Morse's avatar
      [DebugInfo] Nerf placeDbgValues, with prejudice · 00e23889
      Jeremy Morse authored
      CodeGenPrepare::placeDebugValues moves variable location intrinsics to be
      immediately after the Value they refer to. This makes tracking of locations
      very easy; but it changes the order in which assignments appear to the
      debugger, from the source programs order to the order in which the
      optimised program computes values. This then leads to PR43986 and PR38754,
      where variable locations that were in a conditional block are made
      unconditional, which is highly misleading.
      
      This patch adjusts placeDbgValues to only re-order variable location
      intrinsics if they use a Value before it is defined, significantly reducing
      the damage that it does. This is still not 100% safe, but the rest of
      CodeGenPrepare needs polishing to correctly update debug info when
      optimisations are performed to fully fix this.
      
      This will probably break downstream debuginfo tests -- if the
      instruction-stream position of variable location changes isn't the focus of
      the test, an easy fix should be to manually apply placeDbgValues' behaviour
      to the failing tests, moving dbg.value intrinsics next to SSA variable
      definitions thus:
      
        %foo = inst1
        %bar = ...
        %baz = ...
        void call @llvm.dbg.value(metadata i32 %foo, ...
      
      to
      
        %foo = inst1
        void call @llvm.dbg.value(metadata i32 %foo, ...
        %bar = ...
        %baz = ...
      
      This should return your test to exercising whatever it was testing before.
      
      Differential Revision: https://reviews.llvm.org/D58453
      00e23889
    • David Green's avatar
      [Attr] Add missing header for clang example. · f7e7a5f1
      David Green authored
      The examples are easy to miss.
      f7e7a5f1
    • Pavel Labath's avatar
      [lldb/DWARF] Switch to llvm location list parser · 773b849c
      Pavel Labath authored
      Summary:
      This patch deletes the lldb location list parser and teaches the
      DWARFExpression class to use the parser in llvm instead. I have
      centralized all the places doing the parsing into a single
      GetLocationExpression function.
      
      In theory the the actual location list parsing should be covered by llvm
      tests, and this glue code by our existing location list tests, but since
      we don't have that many location list tests, I've tried to extend the
      coverage a bit by adding some explicit dwarf5 loclist handling and a
      test of the dumping code.
      
      For DWARF4 location lists this should be NFC (modulo small differences
      in error handling which should only show up on invalid inputs). In case
      of DWARF5, this fixes various missing bits of functionality, most
      notably, the lack of support for DW_LLE_offset_pair.
      
      Reviewers: JDevlieghere, aprantl, clayborg
      
      Subscribers: lldb-commits, dblaikie
      
      Tags: #lldb
      
      Differential Revision: https://reviews.llvm.org/D71003
      773b849c
    • Pavel Labath's avatar
      [lldb] Improve/fix base address selection in location lists · 329008fd
      Pavel Labath authored
      Summary:
      Lldb support base address selection entries in location lists was broken
      for a long time. This wasn't noticed until llvm started producing these
      kinds of entries more frequently with r374600.
      
      In r374769, I made a quick patch which added sufficient support for them
      to get the test suite to pass. However, I did not fully understand how
      this code operates, and so the fix was not complete. Specifically, what
      was lacking was the ability to handle modules which were not loaded at
      their preferred load address (for instance, due to ASLR).
      
      Now that I better understand how this code works, I've come to the
      conclusion that the current setup does not provide enough information
      to correctly process these entries. In the current setup the location
      lists were parameterized by two addresses:
      - the distance of the function start from the start of the compile unit.
        The purpose of this was to make the location ranges relative to the
        start of the function.
      - the actual address where the function was loaded at. With this the
        function-start-relative ranges can be translated to actual memory
        locations.
      
      The reason for the two values, instead of just one (the load bias) is (I
      think) MachO, where the debug info in the object files will appear to be
      relative to the address zero, but the actual code it refers to
      can be moved and reordered by the linker. This means that the location
      lists need to be "linked" to reflect the locations in the actual linked
      file.
      
      These two bits of information were enough to correctly process location
      lists which do not contain base address selection entries (and so all
      entries are relative to the CU base). However, they don't work with
      them because, in theory two base address can be completely unrelated (as
      can happen for instace with hot/cold function splitting, where the
      linker can reorder the two pars arbitrarily).
      
      To fix that, I split the first parameter into two:
      - the compile unit base address
      - the function start address, as is known in the object file
      
      The new algorithm becomes:
      - the location lists are processed as they were meant to be processed.
        The CU base address is used as the initial base address value. Base
        address selection entries can set a new base.
      - the difference between the "file" and "load" function start addresses
        is used to compute the load bias. This value is added to the final
        ranges to get the actual memory location.
      
      This algorithm is correct for non-MachO debug info, as there the
      location lists correctly describe the code in the final executable, and
      the dynamic linker can just move the entire module, not pieces of it. It
      will also be correct for MachO if the static linker preserves relative
      positions of the various parts of the location lists -- I don't know
      whether it actually does that, but judging by the lack of base address
      selection support in dsymutil and lldb, this isn't something that has
      come up in the past.
      
      I add a test case which simulates the ASLR scenario and demonstrates
      that base address selection entries now work correctly here.
      
      Reviewers: JDevlieghere, aprantl, clayborg
      
      Subscribers: dblaikie, lldb-commits
      
      Tags: #lldb
      
      Differential Revision: https://reviews.llvm.org/D70532
      329008fd
    • James Henderson's avatar
      [test][tools] Add missing and improve testing · dba420bc
      James Henderson authored
      Mostly this adds testing for certain aliases in more explicit ways.
      There are also a few tidy-ups, and additions of missing testing, where
      the feature was either not tested at all, or not tested explicitly and
      sufficiently.
      
      Reviewed by: MaskRay, rupprecht, grimar
      
      Differential Revision: https://reviews.llvm.org/D71116
      dba420bc
    • Mikhail Maltsev's avatar
      [ARM][MVE] Add complex vector intrinsics · 0d1490bf
      Mikhail Maltsev authored
      Summary:
      This patch adds intrinsics for the following MVE instructions:
      * VCADD, VHCADD
      * VCMUL
      * VCMLA
      
      Each of the above 3 groups has a corresponding new LLVM IR intrinsic.
      
      Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen
      
      Reviewed By: MarkMurrayARM
      
      Subscribers: merge_guards_bot, kristof.beyls, hiraditya, cfe-commits, llvm-commits
      
      Tags: #clang, #llvm
      
      Differential Revision: https://reviews.llvm.org/D71190
      0d1490bf
    • David Green's avatar
      d6642ed1
    • Muhammad Omair Javaid's avatar
      [lldb] Xfail TestCallOverriddenMethod.py for aarch64/linux · 7d175cf5
      Muhammad Omair Javaid authored
      This test still fails on Linux aarch64.
      Tested by buildbot running Ubuntu Bionic
      
      Differential Revision: https://reviews.llvm.org/D70722
      7d175cf5
    • David Green's avatar
      [CommandLine] Add missing Callbacks · 4a6e13ad
      David Green authored
      It appears that the cl::bits options are not used anywhere in-tree. In
      the recent addition to add Callback's to the options, the Callback was
      missing from this one. This fixes it by adding the same code from the
      other classes.
      
      It also adds a simple test, of sorts, just to make sure these continue
      compiling.
      4a6e13ad
    • David Green's avatar
      [ARM] Enable MVE masked loads and stores · b1aba037
      David Green authored
      With the extra optimisations we have done, these should now be fine to
      enable by default. Which is what this patch does.
      
      Differential Revision: https://reviews.llvm.org/D70968
      b1aba037