This patch pipes down the `-a|--load-all` crashlog command option to the
Scripted Process initializer to load all the images used by crashed
process instead of only loading the images related to the crashed
thread.

This allows us to recreate artificial frames also for the non-crashed
scripted threads.

rdar://90396265

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This reverts commit 07b17664 as it broke
the buildbots:
    https://lab.llvm.org/buildbot#builders/193/builds/8594

  - Rename IntelPTManager class and files to IntelPTCollector
  - Change GetTimestampCounter API to general trace counter API,
    GetCounter

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

Add facilities for extract-api:
- Structs/classes to hold collected API information: `APIRecord`, `API`
- Structs/classes for API information:
  - `AvailabilityInfo`: aggregated availbility information
  - `DeclarationFragments`: declaration fragments
    - `DeclarationFragmentsBuilder`: helper class to build declaration
      fragments for various types/declarations
  - `FunctionSignature`: function signature
- Serialization: `Serializer`
- Add output file for `ExtractAPIAction`
- Refactor `clang::RawComment::getFormattedText` to provide an
  additional `getFormattedLines` for a more detailed view of comment lines
  used for the SymbolGraph format

Add support for global records (global variables and functions)
- Add `GlobalRecord` based on `APIRecord` to store global records'
  information
- Implement `VisitVarDecl` and `VisitFunctionDecl` in `ExtractAPIVisitor` to
  collect information
- Implement serialization for global records
- Add test case for global records

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

In AMD GPU device code the globals are in AS(1). Before, we crashed if
the global was a structure. Now we simply cast away the AS before we
generate the code to initialize the global.

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

Expose diagnostic events through the SB API. Unlike the progress events,
I opted to use a SBStructuredData so that we can add fields in the
future.

Differential revision: https://reviews.llvm.org/D121818

We have a special case to skip this transform if c1 is 0xffffffff
and x is sext_inreg in order to use sraiw+zext.w. But we were only
checking that we have a sext_inreg opcode, not how many bits are
being sign extended.

This commit adds a check that it is a sext_inreg from i32 so we know for
sure that an sraiw can be created.

The current decision of when to run the verifier is running on the
assumption that nested passes can't affect the validity of the parent
operation, which isn't true. Parent operations may attach any number
of constraints on nested operations, which may not necessarily be
captured (or shouldn't be captured) at a smaller granularity.

This commit rectifies this by properly running the verifier after an
OpToOpAdaptor pass. To avoid an explosive increase in compile time,
we only run verification on the parent operation itself. To do this, a
flag to mlir::verify is added to avoid recursive verification if it isn't
desired.

Fixes #54288

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

Adds basic parsing/sema/serialization support for the #pragma omp teams loop
directive.

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

* 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