* Test the case where a symbol is sometimes linkonce_odr and sometimes weak_odr
* Test the visibility of the symbols at the IR level, after the internalize
  stage of LTO is done. (Previously we only checked the visibility of
  symbols in the final output binary.)

Reviewed By: modimo

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

Includes verifier changes checking the elementtype, clang codegen
changes to emit the elementtype, and ISel changes using the elementtype.

Basically the same as D120527.

Reviewed By: #opaque-pointers, nikic

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

This reverts commit 1eeb2bfe to fix
a bug reported in https://reviews.llvm.org/D121121

Pre-committing a test update to make changes in D121744 more visible.

Interfaces which are internal to a procedure need to be included in
module files if (and only if) they are referenced in the interface of
the procedure. That is, they are needed if they are the interfaces of
dummy or return value procedures.

Fixes #53420

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

Fix the instruction names to match the WebAssembly spec:

 - `i32x4.trunc_sat_zero_f64x2_{s,u}` => `i32x4.trunc_sat_f64x2_{s,u}_zero`
 - `f32x4.demote_zero_f64x2` => `f32x4.demote_f64x2_zero`

Also rename related things like intrinsics, builtins, and test functions to
match.

Reviewed By: aheejin

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

This patch adds lowering for the `pack` and `unpack`
intrinsics.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: schweitz

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



Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>

When dealing with an unconditional branch, the condition can only added
if BB properly dominates the successor.

This is by analogy with HasFlatScratchSTMode and is slightly more
informative than using isGFX940Plus.

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

This patch introduces `DataflowModel`, an abstract base class for dataflow
"models": reusable analysis components that model a particular aspect of program
semantics.

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

This patch adds lowering for some numeric related
intrinsics:
- `exponent`
- `floor`
- `fraction`
- `mod`
- `modulo`
- `nint`
- `not`
- `product`

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld, schweitz

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



Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This test is platform specific. It makes the windows
buildbot fails https://lab.llvm.org/buildbot/#/builders/172/builds/9708

Jussi Maki reported a fatal error like below for a bitfield
CO-RE relocation:
  fatal error: error in backend: Unsupported field expression for
  llvm.bpf.preserve.field.info, requiring too big alignment
The failure is related to kernel struct thread_struct. The following
is a simplied example.

Suppose we have below structure:
  struct t2 {
    int a[8];
  } __attribute__((aligned(64))) __attribute__((preserve_access_index));
  struct t1 {
    int f1:1;
    int f2:2;
    struct t2 f3;
  } __attribute__((preserve_access_index));

Note that struct t2 has aligned 64, which is used sometimes in the
kernel to enforce cache line alignment.

The above struct will be encoded into BTF and the following is what
C code looks like and the struct will appear in the file like vmlinux.h.
  struct t2 {
        int a[8];
        long: 64;
        long: 64;
        long: 64;
        long: 64;
  } __attribute__((preserve_access_index));
  struct t1 {
        int f1: 1;
        int f2: 2;
        long: 61;
        long: 64;
        long: 64;
        long: 64;
        long: 64;
        long: 64;
        long: 64;
        long: 64;
        struct t2 f3;
  } __attribute__((preserve_access_index));

Note that after
  origin_source -> BTF -> new_source
transition, the new source has the same memory layout as the old one
but the alignment interpretation inside the compiler could be different.
The bpf program will use the later explicitly padded structure as in
vmlinux.h.

In the above case, the compiler internal ABI alignment for new struct t1
is 16 while it is 4 for old struct t1. I didn't do a thorough investigation
why the ABI alignment is 16 and I suspect it is related to anonymous padding
in the above.

Current BPF bitfield CO-RE handling requires alignment <= 8 so proper
bitfield operatin can be performed. Therefore, alignment 16 will cause
a compiler fatal error.

To fix the ABI alignment >=16, let us check whether the bitfield
can be held within a 8-byte-aligned range. If this is the case,
we can use alignment 8. Otherwise, a fatal error will be reported.

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

This is now possible because we have a platform independent abstraction
for mutexes.

Reviewed By: lntue, michaelrj

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

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

Since we mark the pseudos as mayLoad but do not provide any MMOs,
isSafeToMove conservatively returns false, stopping MachineLICM from
hoisting the instructions. PseudoLA_TLS_GD does not actually expand to a
load, so stop marking that as mayLoad to allow it to be hoisted, and for
the others make sure to add MMOs during lowering to indicate they're GOT
loads and thus can be freely moved.

Fixes https://github.com/llvm/llvm-project/issues/54372

Reviewed By: MaskRay, arichardson

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

Only PseudoLLA is currently hoisted; this will be fixed in a subsequent
commit.

Use "operands" instead of "operators"

Closes #54397

This was wrongly removed in 9aeb7f03
and makes buildbot fail.

This binary is used in LIT tests.

Test: `bazel run --config=generic_clang -c opt @llvm-project//llvm:llvm-remark-size-diff -- --help`

Reviewed By: dblaikie

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

Commit 3251ba2d ("[Attr] Fix a btf_type_tag AST generation")
added a new type BTFTagAttributedType to the clang AST type
system. There are a few places in lldb needed to handle this type
similar to Attributed type to avoid compilation warning/error
when 'switch' is used to enumerate all types.

Reviewed By: hctim

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

We may be able to refine the conditions for these transforms ( D120648 ).

Reviewed By: MaskRay

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

Reviewed By: hctim

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

This patch adds support for lowering of the `i{a}char` intrinsics from
Fortran to the FIR dialect of MLIR.

This is part of the upstreaming effort from the `fir-dev` branch in [1].

[1] https://github.com/flang-compiler/f18-llvm-project

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: zacharyselk <zrselk@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

We add to ensure that we are observing the correct callstack order in memprof
during symbolization. There was some confusion whether the order of
DIFrame objects were reversed but in reality the leaf function is at
index 0 so no code changes are required.

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

This reverts commit 1b6ff3f4 since
it broke Fuchsia's macOS builders.

This patch adds support for lowering of the `ibclr` intrinsic from Fortran
to the FIR dialect of MLIR.

This is part of the upstreaming effort from the `fir-dev` branch in [1].

[1] https://github.com/flang-compiler/f18-llvm-project



Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>

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

After e5822ded, the call to LargeFunction can be optimized out, as x
is never accessed in main. This is causing the test to fail, because the
out-of-bounds access won't be executed.

Adding an extra read and returning the value should prevent the
optimizer from removing the call.

dense<...> expects ... to be a tensor-literal.
Define this in the grammar in BuiltinAttributes.td,
and reflect this in the reference grammar written in
AttributeParser.cpp.

Reviewed By: rriddle

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

Fixes https://github.com/clangd/clangd/issues/1057

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

This patch adds support for lowering of the `ieor` intrinsic from Fortran
to the FIR dialect of MLIR.

This is part of the upstreaming effort from the `fir-dev` branch in [1].

[1] https://github.com/flang-compiler/f18-llvm-project



Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>

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

STB_GNU_UNIQUE is like STB_GLOBAL with extra semantics:

* gold and ld.lld: changed to STB_GLOBAL if --no-gnu-unique is specified
* glibc: unique even with dlopen `RTLD_LOCAL`, implies DF_1_NODELETE

Therefore, I think it makes sense for --weaken-symbol/--weaken-symbols/--weaken
to change STB_GNU_UNIQUE symbols.

binutils 2.39 will have the same behavior: https://sourceware.org/bugzilla/show_bug.cgi?id=28926

Reviewed By: jhenderson

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