1. Jan 22, 2020
  2. Jan 21, 2020
  3. Jan 22, 2020
  4. Jan 21, 2020
    • Zakk Chen's avatar
      [RISCV] Check the target-abi module flag matches the option · 1256d680
      Zakk Chen authored
      Reviewers: lenary, asb
      
      Reviewed By: lenary
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D72768
      1256d680
    • Diogo Sampaio's avatar
      Revert "[ARM] Follow AACPS standard for volatile bit-fields access width" · 2147703b
      Diogo Sampaio authored
      This reverts commit 6a24339a.
      Submitted using ide button by mistake
      2147703b
    • Diogo Sampaio's avatar
      [ARM] Follow AACPS standard for volatile bit-fields access width · 6a24339a
      Diogo Sampaio authored
      Summary:
      This patch resumes the work of D16586.
      According to the AAPCS, volatile bit-fields should
      be accessed using containers of the widht of their
      declarative type. In such case:
      ```
      struct S1 {
        short a : 1;
      }
      ```
      should be accessed using load and stores of the width
      (sizeof(short)), where now the compiler does only load
      the minimum required width (char in this case).
      However, as discussed in D16586,
      that could overwrite non-volatile bit-fields, which
      conflicted with C and C++ object models by creating
      data race conditions that are not part of the bit-field,
      e.g.
      ```
      struct S2 {
        short a;
        int  b : 16;
      }
      ```
      Accessing `S2.b` would also access `S2.a`.
      
      The AAPCS Release 2019Q1.1
      (https://static.docs.arm.com/ihi0042/g/aapcs32.pdf)
      section 8.1 Data Types, page 35, "Volatile bit-fields -
      preserving number and width of container accesses" has been
      updated to avoid conflict with the C++ Memory Model.
      Now it reads in the note:
      ```
      This ABI does not place any restrictions on the access widths
      of bit-fields where the container overlaps with a non-bit-field member.
       This is because the C/C++ memory model defines these as being separate
      memory locations, which can be accessed by two threads
       simultaneously. For this reason, compilers must be permitted to use a
      narrower memory access width (including splitting the access
       into multiple instructions) to avoid writing to a different memory location.
      ```
      
      I've updated the patch D16586 to follow such behavior by verifying that we
      only change volatile bit-field access when:
       - it won't overlap with any other non-bit-field member
       - we only access memory inside the bounds of the record
      
      Regarding the number of memory accesses, that should be preserved, that will
      be implemented by D67399.
      
      Reviewers: rsmith, rjmccall, eli.friedman, ostannard
      
      Subscribers: ostannard, kristof.beyls, cfe-commits, carwil, olista01
      
      Tags: #clang
      
      Differential Revision: https://reviews.llvm.org/D72932
      6a24339a
    • Simon Pilgrim's avatar
      [TargetLowering] SimplifyDemandedBits ISD::SRA multi-use handling · f04284cf
      Simon Pilgrim authored
      Call SimplifyMultipleUseDemandedBits to peek through extended source args with multiple uses
      f04284cf
    • Benjamin Kramer's avatar
      Make dropTriviallyDeadConstantArrays not quadratic · 81f385b0
      Benjamin Kramer authored
      Only look at the operands of dead constant arrays instead of all
      constant arrays again.
      81f385b0
    • Jinsong Ji's avatar
      [PowerPC][NFC] Reclaim TSFlags bit 6 · d7032bc3
      Jinsong Ji authored
      We removed UseVSXReg flag in https://reviews.llvm.org/D58685
      But we did not reclain the bit 6 it was assigned,
      this will become confusing and a hole later..
      We should reclaim it as early as possible before new bits.
      
      Reviewed By: sfertile
      
      Differential Revision: https://reviews.llvm.org/D72649
      d7032bc3