The instructions produce DLEN bits per cycle. The vsetvli LMUL for these
instructions is the output EMUL. The input EMUL is scaled down by
the vector factor suffix on the instruction name.

So for LMUL=1 there are 2*DLEN bits of result produced over 2 cycles.
This makes SiFive7GetCyclesDefault the correct resource cycles.

Reviewed By: monkchiang

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

The added instructions are incorrectly encoded as a16 ones despite the
'noa16' modifiers.

Reviewed By: foad

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

In an attempt to make it easier to catch errors when parsing the
debug_abbrev section, we should force users to call `parse` before
calling `begin`. In a follow-up change, I will change the return type of
`parse` from `void` to `Error`.

I also explored using the fallible_iterator pattern instead of forcing
users to parse everything up front. I think it would be a useful and
interesting pattern to implement, but it would require more extensive
changes to both DWARFDebugAbbrev and its users. Because my top priority
is improving the safety around parsing debug_abbrev, I'm opting to
preserve existing behavior until I or somebody else has time to refactor
to be able to implement a fallible_iterator.

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

Add support for the Compact C Type Format (CTF) in LLDB. The format
describes the layout and sizes of C types. It is most commonly consumed
by dtrace.

We generate CTF for the XNU kernel and want to be able to use this in
LLDB to debug kernels for which we don't have dSYMs (anymore). CTF is a
much more limited debug format than DWARF which allows is to be an order
of magnitude smaller: a 1GB dSYM can be converted to a handful of
megabytes of CTF. For XNU, the goal is not to replace DWARF, but rather
to have CTF serve as a "better than nothing" debug info format when
DWARF is not available.

It's worth noting that the LLVM toolchain does not support emitting CTF.
XNU uses ctfconvert to generate CTF from DWARF which is used for
testing.

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

Teach LLDB about the ctf (Compact C Type Format) section.

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

We can share the code for both the unmasked and masked cases, and add a missing consistency assert in the process.

This is a subset of Luke's D155063.  I'm splitting pieces and landing them in the process of convincing myself all the individual transforms are in fact correct.  This is the last major piece.

This has an `lldb_private` type in its parameter, it should be in
`lldb-private-types.h`

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

Add support to lower reduction with the multiply operator and
complex type.

Depends on D155007

Reviewed By: razvanlupusoru

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

Thanks to Simon Pilgrim for letting me know about these in
https://reviews.llvm.org/rG9d701c8a8d65.

Propagate Linux Kernel ORC information read from the file to the whole
function CFG once the graph has been built. We have a choice to either
attach ORC state annotation to every instruction, or to the first
instruction in the basic block to conserve processing memory. I chose to
attach to every instruction under --print-orc option which is currently
on by default.

Depends on D155153, D154815

Reviewed By: Amir

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

Add MetadataRewriter::postCFGInitializer().

Reviewed By: jobnoorman

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

This is a subset of Luke's D155063.  I'm splitting pieces and landing them in the process of convincing myself all the individual transforms are in fact correct.

The code structure here is overly verbose.  I'm landing this staging change with the code structure exactly matching the non-masked case to make the following cleanup that commons this all obviously correct.

Read ORC (oops rewind capability) info used for unwinding the stack by
Linux Kernel. The info is stored in .orc_unwind and .orc_unwind_ip
sections. There is also a related .orc_lookup section that is being
populated by the kernel during runtime. Contents of the sections are
sorted for quicker lookup by a post-link objtool.

Unless we modify stack access instructions, we don't have to change ORC
info attributed to instructions in the binary. However, we need to
update instruction addresses and sort both sections based on the new
layout.

For pretty printing, we add "--print-orc" option that prints ORC info
next to instructions in code dumps.

Reviewed By: Amir

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

This test has been failing on sanitizer-x86_64-linux-bootstrap-asan
since it was commited. Removing this test while I work on reproducing
this.

Example: https://lab.llvm.org/buildbot/#/builders/168/builds/14579

This patch moves a few tests that were still using std::fprintf to
using TEST_REQUIRE instead, which provides a single point to tweak
for platforms that don't implement fprintf. As a fly-by fix, it also
avoids including `time_utils.h` in filesystem_clock.cpp when it is
not required, since that header makes some pretty large assumptions
about the platform it is on.

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

There are cases in DWARF4 when Skeleton CU has ranges, but dwo CU doesn't.
Bug was introduced in new DWARFRewriter where for DWARF4 it would fall through
to DWARF5 case.

Reviewed By: maksfb

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

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

The DWO Unit DIE, doesn't have low_pc/high_pc, so we were printing this error
for valid cases.

Reviewed By: maksfb

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

GCC and existing codebases allow the use of integral values to be used
with this constraint. A recent change D133914 in this area started causing asserts.
Removing the assert is enough as the rest of the code works fine.

rdar://109675485

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

The greediness of the operand matching regular expressions made
the test pass even though an operand is missing.

Also makes some minor consistency edits in the cuSparseLt wrapper lib.

Reviewed By: Peiming, K-Wu

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

Setting initial offset of DIE to input DIE. This is to make "printf" debugging
easier.

Reviewed By: maksfb

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

ENABLE_X86_RELAX_RELOCATIONS has defaulted to on
(c41a18cf) for nearly 3 years.
As a clean-up, remove overrides from some early adopters.

Change OHOS to use true as agreed by the patch author D145227.

This is a subset of Luke's D155063.  I'm splitting pieces and landing them in the process of convincing myself all the individual transforms are in fact correct.

This particular change involves a slightly ugly bit of code to match the glue to the mask.  I'm staging it this way as I ran into a bit of weirdness when commoning mask operands, and wanted to isolate the complexity.

To fix expensive check builds that were failing when using MSVC's
std::string_view::iterator::operator*, I added a few expressions like
&*std::string_view::begin.  @nico pointed out that this is literally the
same thing and more clearly expressed as std::string_view::data.

Link: https://github.com/llvm/llvm-project/issues/63740

Reviewed By: #libc_abi, ldionne, philnik, MaskRay

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

This is an attempt at mimicing the method in which
threadprivate handles the following type of variables:

program main
  integer :: i
  !$omp declare target to(i)
end

Which essentially generates a GlobalOp for the variable (which
would normally only be an alloca) when it's instantiated. The
main difference is there is no operation generated within the
function, instead the declare target attribute is appended
later within handleDeclareTarget.

Reviewers: kiranchandramohan

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

Very minor change, just making sure each step is obvious and easy to follow.

This is a subset of Luke's D155063.  I'm splitting pieces and landing them in the process of convincing myself all the individual transforms are in fact correct.

The early outlining pass was erasing target functions that need to be
kept. It should only erase functions that contain target ops.

We have the SEW operand access repeating in all paths, common it up to make the code easier to read.

This is a subset of Luke's D155063.  I'm splitting pieces and landing them in the process of convincing myself all the individual transforms are in fact correct.

The problem appeared as a segfault for case like this:
```
type t
character(11), allocatable :: c
end type
character(12), alloctable :: x
type(t) y
y = t(x)
```

The frontend representes `y = t(x)` as `y=t(c=%SET_LENGTH(x,11_8))`.
When 'x' is unallocated the hlfir.set_length lowering results in
segfault. It could probably be handled in hlfir.set_length lowering
by using NULL base for the hlfir.declare depending on the allocation
status of 'x', but I am not sure if !hlfir.expr, in general, is supposed
to represent an expression created from unallocated allocatable.
I believe in Fortran that would mean referencing an unallocated
allocatable, which is not allowed.

I decided to special case `SET_LENGTH` in structure constructor,
so that we use its 'x' operand as the RHS for the assign operation
implying the isAllocatable check for cases when 'x' is allocatable.
This requires setting keep_lhs_length_if_realloc flag for the assign
operation. Note that when the component being intialized has
deferred length the frontend does not produce `SET_LENGTH`.

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

This seems to match https://gcc.gnu.org/install/specific.html#powerpc-x-eabi

It seems that anything with OS `none` (although that doesn’t seem to be distinguished from `unknown`) or with environment `eabi` should be treated as bare-metal.
Since this seems to have been handled on a case-by-case basis in the past ([arm](https://reviews.llvm.org/D33259), [riscv](https://reviews.llvm.org/D91442), [aarch64](https://reviews.llvm.org/D111134)), what I am proposing here is to add another case to the list to also handle `powerpc[64][le]-unknown-unknown-eabi` using the `BareMetal` toolchain, following the example of the existing cases. (We don’t care about powerpc64 and powerpc[64]le, but it seemed appropriate to lump them in.)

At Indel, we have been building bare-metal embedded applications that run on custom PowerPC and ARM systems with Clang and LLD for a couple of years now, using target triples `powerpc-indel-eabi`, `powerpc-indel-eabi750`, `arm-indel-eabi`, `aarch64-indel-eabi` (which I just learned from D153430 is wrong and should be `aarch64-indel-elf` instead, but that’s a different matter). This has worked fine for ARM, but for PowerPC we have been unable to call the linker (LLD) through the Clang driver, because it would insist on calling GCC as the linker, even when told `-fuse-ld=lld`. That does not work for us, there is no GCC around. Instead we had to call `ld.lld` directly, introducing some special cases in our build system to translate between linker-via-driver and linker-called-directly command line arguments. I have now dug into why that is, and found that the difference between ARM and PowerPC is that `arm-indel-eabi` hits a special case that causes the Clang driver to instantiate a `BareMetal` toolchain that is able to call LLD and works the way we need, whereas `powerpc-indel-eabi` lands in the default case of a `Generic_ELF` (subclass of `Generic_GCC`) toolchain which expects GCC.

Reviewed By: MaskRay, michaelplatings, #powerpc, nemanjai

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

Removing the x86-specific node helps further folding and improves commutativity

Check the combination of reduction operator and types. This is
currently not checking common block and composite types.

Depends on D155105

Reviewed By: razvanlupusoru

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

Remove duplicate of the getDesignatorNameIfDataRef() function.

Reviewed By: kiranchandramohan

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

This is a subset of Luke's D155063.  I'm splitting pieces and landing them in the process of convincing myself all the individual transforms are in fact correct.

In this case, we're simplifying based on the assumption that all of our vmerge operands have mask operands.  This is a fundemental property of a vmerge.

There was a bug with the -funderscoring / -fno-underscoring options from (https://reviews.llvm.org/D140795) that prevented the driver option from controlling the underscoring behaviour and instead the behaviour could only be controlled by the pass option instead of the driver option. The driver test case did not catch the bug and also needed to be updated.

Reviewed By: awarzynski

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

SubOpAliases maps a sub-operand name to the respective operand's index
and the sub-operand number within this operand. The operand index is
used for the Operands array.

Currently MIOperandNo is used as the operand index, which is not
correct. For example, if there are 2 operands with 3 sub-operands each:

  (ins (bdladdr12onlylen4 $B1, $D1, $L1):$BDL1,
       (bdladdr12onlylen4 $B2, $D2, $L2):$BDL2)

then B2's operand index will be 3, but the correct value is 1.

Reviewed By: jyknight

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

Combine mul (f32) + fptrunc (f32->f16) to "v_fma_mixlo_f16 mulSrc1, mulSrc2, 0".

Differential Revision: https://reviews.llvm.org/D153544
Reviewers: arsenm, foad

When I landed the EmulateUnsupportedFloats, I'd negligently included
an assert that needed to run for the pass to be correct. Previous
emergency fix commits removed the assert. This commit re-adds the
"can't happen" testing as an emitOpError() and aborting the rewrite,
thus allowing it to function in no-assertions builds.

Reviewed By: kuhar

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