Skip to content
GitLab
  1. May 20, 2020
    • Dimitry Andric's avatar
      [arm] Add big-endian version of pcrel fixups for adr instructions · f79cd71e
      Dimitry Andric authored 
      Summary:
In 2e24219d, a number of ARM pcrel fixups were resolved at assembly
time, to solve PR44929. This only covered little-endian ARM however, so
add similar fixups for big-endian ARM. Also extend the test case to
cover big-endian ARM.

Reviewers: hans, psmith, MaskRay

Reviewed By: psmith, MaskRay

Subscribers: kristof.beyls, hiraditya, danielkiss, emaste, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79774

(cherry picked from commit fc373522)
      f79cd71e
    • David Green's avatar
      [ARM] Only produce qadd8b under hasV6Ops · f3164f75
      David Green authored 
      When compiling for a arm5te cpu from clang, the +dsp attribute is set.
This meant we could try and generate qadd8 instructions where we would
end up having no pattern. I've changed the condition here to be hasV6Ops
&& hasDSP, which is what other parts of ARMISelLowering seem to use for
similar instructions.

Fixed PR45677.

Differential Revision: https://reviews.llvm.org/D78877

(cherry picked from commit 88071390)
      f3164f75
  3. May 19, 2020
  5. May 08, 2020
  7. May 07, 2020
    • David Green's avatar
      [MachineSink] Fix for breaking phi edges with instructions with multiple defs · bab8d179
      David Green authored 
      BreakPHIEdge would be set based on whether the instruction needs to
insert a new critical edge to allow sinking into a block where the uses
are PHI nodes. But for instructions with multiple defs it would be reset
on the second def, allowing the instruciton to sink where it should not.

Fixes PR44981

Differential Revision: https://reviews.llvm.org/D78087

(cherry picked from commit 44c4ba34)
      bab8d179
    • Aaron Puchert's avatar
      PR45000: Let Sema::SubstParmVarDecl handle default args of lambdas in initializers · 9c80516d
      Aaron Puchert authored 
      Summary:
We extend the behavior for local functions and methods of local classes
to lambdas in variable initializers. The initializer is not a separate
scope, but we treat it as such.

We also remove the (faulty) instantiation of default arguments in
TreeTransform::TransformLambdaExpr, because it doesn't do proper
initialization, and if it did, we would do it twice (and thus also emit
eventual errors twice).

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D76038

(cherry picked from commit f43859a0)
      9c80516d
    • Yonghong Song's avatar
      BPF: fix a CORE optimization bug · 1d1469ab
      Yonghong Song authored 
      For the test case in this patch like below
  struct t { int a; } __attribute__((preserve_access_index));
  int foo(void *);
  int test(struct t *arg) {
      long param[1];
      param[0] = (long)&arg->a;
      return foo(param);
  }

The IR right before BPF SimplifyPatchable phase:
  %1:gpr = LD_imm64 @"llvm.t:0:0$0:0"
  %2:gpr = LDD killed %1:gpr, 0
  %3:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
  STD killed %3:gpr, %stack.0.param, 0
After SimplifyPatchable phase, the incorrect IR is generated:
  %1:gpr = LD_imm64 @"llvm.t:0:0$0:0"
  %3:gpr = ADD_rr %0:gpr(tied-def 0), killed %1:gpr
  CORE_MEM killed %3:gpr, 306, %0:gpr, @"llvm.t:0:0$0:0"

Note that CORE_MEM pseudo op is introduced to encode
memory operations related to CORE. In the above, we intend
to check whether we have a store like
   *(%3:gpr + 0) = ...
and if this is the case, we could replace it with
   *(%0:gpr + @"llvm.t:0:0$0:0"_ = ...

Unfortunately, in the above, IR for the store is
   *(%stack.0.param + 0) = %3:gpr
and transformation should not happen.

Note that we won't have problem if the actual CORE
dereference (arg->a) happens.

This patch fixed the problem by skip CORE optimization if
the use of ADD_rr result is not the base address of the store
operation.

Differential Revision: https://reviews.llvm.org/D78466

(cherry picked from commit 3cb7e7bf)
      1d1469ab
    • Fangrui Song's avatar
      [Sema] Allow function attribute patchable_function_entry on aarch64_be · 98f9f73f
      Fangrui Song authored 
      Reviewed By: nickdesaulniers

Differential Revision: https://reviews.llvm.org/D79495

(cherry picked from commit 57a1c1be)
      98f9f73f
  9. May 04, 2020
    • Fangrui Song's avatar
      [llvm-objcopy] Avoid invalid Sec.Offset after D79229 · 8e7ae355
      Fangrui Song authored 
      To avoid undefined behavior caught by -fsanitize=undefined on binary-paddr.test

  void SectionWriter::visit(const Section &Sec) {
    if (Sec.Type != SHT_NOBITS)
      // Sec.Contents is empty while Sec.Offset may be out of bound
      llvm::copy(Sec.Contents, Out.getBufferStart() + Sec.Offset);
  }

(cherry picked from commit 762fb1c4)
      8e7ae355
  11. May 02, 2020
    • Fangrui Song's avatar
      [llvm-objcopy] -O binary: skip empty sections · d4d4c6bf
      Fangrui Song authored 
      After SHF_ALLOC sections are ordered by LMA:

* If initial sections are empty, GNU objcopy skips their contents while we
  emit leading zeros. (binary-paddr.test %t4)
* If trailing sections are empty, GNU objcopy skips their contents while we
  emit trailing zeros. (binary-paddr.test %t5)

This patch matches GNU objcopy's behavior. Linkers don't keep p_memsz
PT_LOAD segments. Such empty sections would not have a containing
PT_LOAD and `Section::ParentSegment` might be null if linkers fail to
optimize the file offsets (lld D79254).

In particular, without D79254, the arm Linux kernel's multi_v5_defconfig
depends on this behavior: in `vmlinux`, an empty .text_itcm is mapped at
a very high address (0xfffe0000) but the kernel does not expect
`objcopy -O binary` to create a very large `arch/arm/boot/Image`
(0xfffe0000-0xc0000000 ~= 1GiB). See https://bugs.llvm.org/show_bug.cgi?id=45632

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D79229

(cherry picked from commit ec786906)
      d4d4c6bf
  13. May 01, 2020
  15. Apr 30, 2020
  17. Apr 28, 2020
  19. Apr 23, 2020
  21. Apr 17, 2020