The header `assert.h` needs to be included in order to use `assert` in the code.
When building NVPTX `deviceRTLs` on a CUDA free system, it requires headers from
`gcc-multilib`, which some systems don't have. This patch drops the use of
`assert` in common parts of `deviceRTLs`. In light of
`openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.h`, a code block
```
if (!cond)
  __builtin_trap();
```
is being used. The builtin will be translated to `call void @llvm.trap()`, and
the corresponding PTX is `trap;`.

Reviewed By: JonChesterfield

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

Use `StringLiteral` for function return type if it is known to return
constant string literals only.

This will make it visible to API users, that such values can be safely
stored, since they refers to constant data, which will never be deallocated.

`StringRef` is general is not safe to store for a long term,
since it might refer to temporal data allocated in heap.

Reviewed By: mehdi_amini, bkramer

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

binutils 2.36 introduced the new section flag SHF_GNU_RETAIN (for ELFOSABI_GNU &
ELFOSABI_FREEBSD) to mark a sections as a GC root. Several LLVM side toolchain
folks (including me) were involved in the design process of SHF_GNU_RETAIN and
were happy with this proposal.

Currently GNU ld only respects SHF_GNU_RETAIN semantics for ELFOSABI_GNU &
ELFOSABI_FREEBSD object files
(https://sourceware.org/bugzilla/show_bug.cgi?id=27282).  GNU ld sets EI_OSABI
to ELFOSABI_GNU for relocatable output
(https://sourceware.org/bugzilla/show_bug.cgi?id=27091). In practice the single
value EI_OSABI is neither a good indicator for object file compatibility, nor a
useful mechanism marking used ELF extensions.

For input, we respect SHF_GNU_RETAIN semantics even for ELFOSABI_NONE object
files. This is compatible with how LLD and GNU ld handle (mildly useful) STT_GNU_IFUNC
/ (emitted by GCC, considered misfeature by some folks) STB_GNU_UNIQUE input.
(As of LLVM 12.0.0, the integrated assembler does not set ELFOSABI_GNU for
STT_GNU_IFUNC/STB_GNU_UNIQUE).
Arguably STT_GNU_IFUNC/STB_GNU_UNIQUE probably need indicators in object files
but SHF_GNU_RETAIN is more likely accepted by more OSABI platforms.

For output, we take a step further than GNU ld: we don't promote ELFOSABI_NONE
to ELFOSABI_GNU for all output.

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

In GCC emitted .debug_info sections, R_386_GOTOFF may be used to
relocate DW_AT_GNU_call_site_value values
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98946).

R_386_GOTOFF (`S + A - GOT`) is one of the `isStaticLinkTimeConstant` relocation
type which is not PC-relative, so it can be used from non-SHF_ALLOC sections. We
current allow new relocation types as needs come. The diagnostic has caught some
bugs in the past.

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

To allow it usage for Operation classes defined outside of `mlir` namespace.

Reviewed By: mehdi_amini

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

Warnings have been added for three cases (PR41905): (1) missing debug info, (2)
the source file cannot be found, (3) the debug info points at a line beyond the
end of the file.

(1) is probably less useful. This was brought up once on
http://lists.llvm.org/pipermail/llvm-dev/2020-April/141264.html and two
internal users mentioned it to me that it was annoying. (I personally
find the warning confusing, too.)

Users specify --source to get additional information if sources happen to be
available.  If sources are not available, it should be obvious as the output
will have no interleaved source lines. The warning can be especially annoying
when using llvm-objdump -S on a bunch of files.

This patch drops the warning when there is no debug info.
(If LLVMSymbolizer::symbolizeCode returns an `Error`, there will still be
an error. There is currently no test for an `Error` return value.
The only code path is probably a broken symbol table, but we probably already emit a warning
in that case)

`source-interleave-prefix.test` has an inappropriate "malformed" test - the test simply has no
.debug_* because new llc does not produce debug info when the filename is empty (invalid).
I have tried tampering the header of .debug_info/.debug_line but llvm-symbolizer does not warn.
This patch does not intend to add the missing test coverage.

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

* Introduce separate `RankedTensorOf` class. Use it as base class for `AnyRankedTensor`.
* Add C++ class specification (`::mlir::MemRefType`) to `MemRefRankOf` and `StaticShapeMemRefOf`.

Reviewed By: ftynse

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

When widening, each half of the v2s16 operands needs to be sign extended
for G_ASHR or zero extended for G_LSHR.

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

SALU min/max s32 instructions exist so use them. This means that
regbankselect can handle min/max much like add/sub/mul/shifts.

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

This revision takes advantage of recent extensions to vectorization to refactor contraction detection into a bona fide Linalg interface.
The mlit-linalg-ods-gen parser is extended to support adding such interfaces.
The detection that was originally enabling vectorization is refactored to serve as both a test on a generic LinalgOp as well as to verify ops that declare to conform to that interface.

This is plugged through Linalg transforms and strategies but it quickly becomes evident that the complexity and rigidity of the C++ class based templating does not pay for itself.
Therefore, this revision changes the API for vectorization patterns to get rid of templates as much as possible.
Variadic templates are relegated to the internals of LinalgTransformationFilter as much as possible and away from the user-facing APIs.

It is expected other patterns / transformations will follow the same path and drop as much C++ templating as possible from the class definition.

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

This patch effectively does the following 3 things:

 - Centralize the logic to figure out if a compiler flag is supported.
 - Stop sanity checking whether the compiler works at all. While useful,
   that's not the decorator's responsibility.
 - Invoke the compiler with xcrun on Darwin so we know where to find the
   sysroot.

On my macOS Big Sur system, the clang invocation couldn't find libSystem
and would fail the sanity check in the decorator. This meant that the
test suite would always try to run the ASan/UBSan/TSan tests, regardless
of whether compiler-rt was built.

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

This patch adds logic in the InputOutputTestAction frontend action for
reading input from stdin. Without this patch the following fails:
```
    flang-new -fc1 -test-io -
```

The implementation of `InputOutputTestAction` is cleaned-up and a test
for reading from stdin is added.

Note that there's a difference between `-test-io` and e.g. `-E` in terms
of file I/O. The frontend action for the former handles all file I/O on
it's own. Conversely, the action corresponding to -E relies on the
prescanner API to handle this.

Currently we can't test reading from stdin for `flang-new -`. In this
case `libclangDriver` assumes `-x -c`. This in turn leads to `flang-new
-cc1`, which is not supported.

According to my reading of http://eel.is/c++draft/filesystems#fs.class.path,
the Standard doesn't actually mention that this should work. Since other
implementations don't allow it, allowing it in libc++ is just setting a
portability trap.

Supersedes https://reviews.llvm.org/D89865.

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

For CS profile generation, the process of call stack unwinding is time-consuming since for each LBR entry we need linear time to generate the context( hash, compression, string concatenation). This change speeds up this by grouping all the call frame within one LBR sample into a trie and aggregating the result(sample counter) on it, deferring the context compression and string generation to the end of unwinding.

Specifically, it uses `StackLeaf` as the top frame on the stack and manipulates(pop or push a trie node) it dynamically during virtual unwinding so that the raw sample can just be recoded on the leaf node, the path(root to leaf) will represent its calling context. In the end, it traverses the trie and generates the context on the fly.

Results:
Our internal branch shows about 5X speed-up on some large workloads in SPEC06 benchmark.

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

Before this patch, feature-test macros didn't take special availability
markup into account, which means that feature-test macros can sometimes
appear to "lie". For example, if you compile in C++20 mode and target
macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided
even though the <filesystem> declarations are marked as unavailable.
This patch fixes that.

rdar://68142369

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

Patch by Khem Raj.

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

This fixes Bugzilla #48894 for Arm, where it
was reported that -Wa,-march was not being handled
by the integrated assembler.

This was previously fixed for -Wa,-mthumb by
parsing the argument in ToolChain::ComputeLLVMTriple
instead of CollectArgsForIntegratedAssembler.
It has to be done in the former because the Triple
is read only by the time we get to the latter.

Previously only mcpu would work via -Wa but only because
"-target-cpu" is it's own option to cc1, which we were
able to modify. Target architecture is part of "-target-triple".

This change applies the same workaround to -march and cleans up
handling of -Wa,-mcpu at the same time. There were some
places where we were not using the last instance of an argument.

The existing -Wa,-mthumb code was doing this correctly,
so I've just added tests to confirm that.

Now the same rules will apply to -Wa,-march/-mcpu as would
if you just passed them to the compiler:
* -Wa/-Xassembler options only apply to assembly files.
* Architecture derived from mcpu beats any march options.
* When there are multiple mcpu or multiple march, the last
  one wins.
* If there is a compiler option and an assembler option of
  the same type, we prefer the one that fits the input type.
* If there is an applicable mcpu option but it is overruled
  by an march, the cpu value is still used for the "-target-cpu"
  cc1 option.

Reviewed By: nickdesaulniers

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

Add support for option -J/-module-dir in the new Flang driver.  This
will allow for including module files in other directories, as the
default search path is currently the working folder. This also provides
an option of storing the output module in the specified folder.

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

These function makes it easier to write generic unit tests for the
format header. It solves the issue where it's not possible to use
  `templated_prefix"foo"`
where `templated_prefix` resolves to: nothing, `L`, `u8`, `u`,
or `U`. The templated_prefix would be more faster during execution.

Reviewed By: ldionne, #libc, curdeius

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

These are variations of a missed analysis noted in:
https://llvm.org/PR48984

In 85e8e624, these tests were modified
to work with AVR, but the regex matchers were finicky and required a
fix forward patch, being this.

We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

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

This patch adds 'XFAIL: avr' to 2 Generic CodeGen tests, bringing the
Generic CodeGen tests for AVR to a pass, with only two XFAILures.

After this patch, the Generic CodeGen tests pass on AVR.

This fixes the vast majority of remaining failing AVR Generic CodeGen
tests.

This method of the dbgeng debugger driver used to just "pass", as setting
dbgeng free running still leads to numerous errors. This wasn't a problem
in the past because, as it turns out, nothing called the go method.
However, a recent refactor uses it.

Rather than launch dbgeng free running, instead have it single step one
step forwards. This is slow, but it makes progress, where previously we
weren't.

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

This new action encapsulates all actions that require the prescanner to
be run before proceeding with other processing. By adding this new
action, we are better equipped to control which actions _do_ run the
prescanner and which _do not_.

The following actions that require the prescanner are refactored to
inherit from `PrescanAction`:
  * `PrintPreprocessedAction`
  * `ParseSyntaxOnlyAction` .

New virtual method is introduced to facilitate all this:
  * `BeginSourceFileAction`
Like in Clang, this method is run inside `BeginSourceFile`. In other
words, it is invoked before `ExecuteAction` for the corresponding
frontend action is run. This method allows us to:
  * carry out any processing that is always required by the action (e.g.
    run the prescanner)
  * fine tune the settings/options on a file-by-file basis (e.g. to
    decide between fixed-form and free-form based on file extension)

This patch implements non-functional-changes.

Reviewed By: FarisRehman

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

This patch migrates cost values and arithmetic to work on InstructionCost.
When the interfaces to TargetTransformInfo are changed, any InstructionCost
state will propagate naturally.

See this patch for the introduction of the type: https://reviews.llvm.org/D91174
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146408.html

Reviewed By: david-arm, fhahn

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

Tags: #clang

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

This patch extends the condition collection logic to allow adding
conditions from pre-headers to loop headers, by allowing cases where the
target block dominates some of its predecessors.

When deducing a reference type for forwarding references prevent
adding default address space of a template argument if it is given.

This got reported in PR48896 because in OpenCL all parameters are
in private address space and therefore when we initialize a
forwarding reference with a parameter we should just inherit the
address space from it i.e. keep __private instead of __generic.

Tags: #clang

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

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

If amdgpu-unsafe-fp-atomics is specified, allow {flat|global}_atomic_add_f32 even if atomic modes don't match.

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

It was discussed a few years ago and agreed that it makes sense to
remove this assertion as other targets do not perform similar register
size checking in inline assembly constraint logic, so the check just
adds a needless barrier on AVR.

This patch removes the assertion and removes 'XFAIL' from two Generic
CodeGen tests for AVR as a result.

This makes sure that AddClang.cmake is installed alongside other Clang
CMake modules. This mirrors LLVM and MLIR in this respect and is
required when building the new Flang driver out of tree (as it depends
on Clang and includes AddClang.cmake).

Reviewed By: bogner

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