AMDGPU/GlobalISel: RegBankSelect for llvm.amdgcn.s.buffer.load

llvm-svn: 361023

AMDGPU/GlobalISel: Use subreg index instead of extra unmerge

This saves instructions and extra steps, but I'm not sure about
introducing subregister indexes at this point.

llvm-svn: 361022

AMDGPU/GlobalISel: Use waterfall loop for buffer_load

This adds support for more complex waterfall loops that need to handle
operands > 32-bits, and multiple operands.

llvm-svn: 361021

GlobalISel: Fix missing version of customFor

Add the list of pairs analagous, like legalFor and customFor has.

llvm-svn: 361020

GlobalISel: Add fp<->int casts to MachineIRBuilder

llvm-svn: 361019

GlobalISel: Add MIRBuilder wrappers for bitcount instructions

Various expansions use these.

llvm-svn: 361018

[MinGW] Include --enable-auto-import in the help listing

Libtool concludes that the linker doesn't support shared libraries,
unless this flag is listed in the output of --help.

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

llvm-svn: 361017

[MinGW] Implement the -v and --version flags for the MinGW driver

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

llvm-svn: 361016

[MinGW] Implement --help for the MinGW driver

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

llvm-svn: 361015

[MinGW] Allow requesting PDB output without giving a file name

When integrating PDB output in mingw targeting build systems, it
might be a lot of extra work to specify unique file names for
the pdb output. Therefore allow omitting the actual file name
and let it implicitly be the same name as the linker output, with
a pdb extension.

As the current form of the pdb option takes a separate parameter value,
e.g. "-pdb out.pdb", it is impractical to leave out the parameter value.

Therefore, introduce a second syntax for the option, with an equals
sign, like -pdb=out.pdb, where the value easily can be omitted.

The form -pdb= for requesting pdb files with an implicit name should
work fine, even though it looks a bit unconventional in that form.

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

llvm-svn: 361014

[ELF][test] Reorganize some R_*_NONE tests

Change R_{386,AARCH64}_NONE yaml2obj tests/icf10.test to use assembly

Add relocation-none-{arm,x86_64}.s.
  Check the referenced section survives under --gc-sections.
  Check -r copies R_X86_64_NONE R_AARCH64_NONE. (Elf*_Rel arches currently have a bug)
  Delete the dtrace tests as they are covered by the R_X86_64_NONE test.

Reviewed By: ruiu

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

llvm-svn: 361013

[X86] Pull out IsNOT helper. NFCI.

Return the input value for the NOT pattern: (xor X, -1) -> X

llvm-svn: 361012

[analyzer] Validate checker option names and values

Validate whether the option exists, and also whether the supplied value is of
the correct type. With this patch, invoking the analyzer should be, at least
in the frontend mode, a lot safer.

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

llvm-svn: 361011

minidump: Use MemoryList parsing code from llvm

llvm-svn: 361010

Re-land r360859: "[MergeICmps] Simplify  the code."

With a fix for PR41917: The predecessor list was changing under our feet.

-  for (BasicBlock *Pred : predecessors(EntryBlock_)) {
+  while (!pred_empty(EntryBlock_)) {
+    BasicBlock* const Pred = *pred_begin(EntryBlock_);

llvm-svn: 361009

[AMDGPU] detect WaW hazards when moving/merging load/store instructions

Summary:
    In order to combine memory operations efficiently, the load/store
    optimizer might move some instructions around. It's usually safe
    to move instructions down past the merged instruction because the
    pass checks if memory operations can be re-ordered.

    Though, the current logic doesn't handle Write-after-Write hazards.

    This fixes a reflection issue with Monster Hunter World and DXVK.

    v2: - rebased on top of master
        - clean up the test case
        - handle WaW hazards correctly

    Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=40130

Original patch by Samuel Pitoiset.

Reviewers: tpr, arsenm, nhaehnle

Reviewed By: nhaehnle

Subscribers: ronlieb, arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye

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

llvm-svn: 361008

[Lex] Allow to consume tokens while preprocessing

Summary:
By adding a hook to consume all tokens produced by the preprocessor.
The intention of this change is to make it possible to consume the
expanded tokens without re-runnig the preprocessor with minimal changes
to the preprocessor and minimal performance penalty when preprocessing
without recording the tokens.

The added hook is very low-level and reconstructing the expanded token
stream requires more work in the client code, the actual algorithm to
collect the tokens using this hook can be found in the follow-up change.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: eraman, nemanjai, kbarton, jsji, riccibruno, cfe-commits

Tags: #clang

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

llvm-svn: 361007

[analyzer] Insert checker options into AnalyzerOption::ConfigTable

The more entries we have in AnalyzerOptions::ConfigTable, the more helpful
debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit
the entire state of the analyzer, minus the frontend flags.

It would be nice to reserve the config table specifically to checker options
only, as storing the regular analyzer configs is kinda redundant.

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

llvm-svn: 361006

[AArch64][SVE2] Asm: add saturating multiply-add long instructions

Summary:
Patch adds support for indexed and unpredicated vectors forms of the
following instructions:

    * SQDMLALB, SQDMLALT, SQDMLSLB, SQDMLSLT

The specification can be found here:
https://developer.arm.com/docs/ddi0602/latest

Reviewed By: SjoerdMeijer

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

llvm-svn: 361005

[NFC] Fix line endings in OpenCL tests

llvm-svn: 361004

[AArch64][SVE2] Asm: add integer multiply-add long instructions

Summary:
Patch adds support for indexed and unpredicated vectors forms of the
following instructions:

    * SMLALB, SMLALT, UMLALB, UMLALT, SMLSLB, SMLSLT, UMLSLB, UMLSLT

The specification can be found here:
https://developer.arm.com/docs/ddi0602/latest

Reviewed By: rovka

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

llvm-svn: 361003

[AArch64][SVE2] Asm: add integer multiply long instructions

Summary:
Patch adds support for indexed and unpredicated vectors forms of the
following instructions:

    * SMULLB, SMULLT, UMULLB, UMULLT, SQDMULLB, SQDMULLT

The specification can be found here:
https://developer.arm.com/docs/ddi0602/latest

Reviewed By: rovka

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

llvm-svn: 361002

[MergeICmps] Add test from PR41917.

llvm-svn: 361001

Make DWARFContext dwo-aware and port debug_info sections over

Summary:
The previous attempt and moving section handling over to DWARFContext
(D59611) failed because it did not take into account the dwo sections
correctly. All DWARFContexts (even those in SymbolFileDWARFDwo) used the
main module for loading the sections, but in the dwo scenario some
sections should come from the dwo file.

This patch fixes that by making the DWARFContext aware of whether it a
dwo context or a regular one. A dwo context gets two sections lists, and
it knows where to look for a particular type of a section. This isn't
fully consistent with how the llvm DWARFContext behaves, because that
one leaves it up to the user to know whether it should ask for a dwo
section or not. However, for the time being, it seems useful to have a
single entity which knows how to peice together the debug info in dwo
and non-dwo scenarios. The rough roadmap for the future is:
- port over the rest of the sections to DWARFContext
- find a way to get rid of SymbolFileDWARFDwo/Dwp/DwpDwo. This will
  likely involve adding the ability for the DWARFContext to spawn
  dwo sub-contexts, similarly to how it's done in llvm.
- get rid of the special handling of the "dwo" contexts by making
  sure everything knows whether it should ask for the .dwo version of
  the section or not (similarly to how llvm's DWARFUnits do that)

To demonstrate how the DWARFContext should behave in this new world, I
port the debug_info section (which is debug_info.dwo in the dwo file)
handling to DWARFContext. The rest of the sections will come in
subsequent patches.

Reviewers: aprantl, clayborg, JDevlieghere

Subscribers: zturner, lldb-commits

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

llvm-svn: 361000

Suppress false-positive GCC -Wreturn-type warning.

llvm-svn: 360999

Fix crash if, during evaluation of __builtin_object_size, we try to load
through an invalid base.

llvm-svn: 360998

Fix alignment check to check the alignment of the intended type.

llvm-svn: 360997

[ClangFormat] Editor integrations inherit default style from clang-format binary

Summary:
This allows downstream customizations to the default style to work without
needing to also modify the editor integrations.

Reviewers: ilya-biryukov

Reviewed By: ilya-biryukov

Subscribers: cfe-commits

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

llvm-svn: 360996

Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

This reinstates r360974, reverted in r360988, with a fix for a
static_assert failure on 32-bit builds: force Type base class to have
8-byte alignment like the rest of Clang's AST nodes.

llvm-svn: 360995

[Clang][Docs] Document __FILE_NAME__. NFC

Document the `__FILE_NAME__` preprocessor extension.

llvm-svn: 360994

[Bugpoint] Only run plugins tests if plugins are enabled

This is a followup to r360991 which applies the same logic to LLVM.

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

llvm-svn: 360993

[X86] Add FeatureFastScalarShiftMasks and FeatureFastVectorShiftMasks to the ignore list for inlining compatibility.

These are tuning flags and won't cause any codegen issue if we inline a function
with a different value.

llvm-svn: 360992

[Analysis] Only run plugins tests if plugins are actually enabled

When plugins aren't enabled, don't try to run plugins tests. Don't
enable plugins unconditionally based on the platform, instead check
if LLVM shared library is actually being built which may not be the
case for every host configuration, even if the host itself supports
plugins.

This addresses test failures introduced by r360891/D59464.

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

llvm-svn: 360991

[PowerPC] Support .reloc *, R_PPC{,64}_NONE, *

This can be used to create references among sections. When --gc-sections
is used, the referenced section will be retained if the origin section
is retained.

llvm-svn: 360990

[GlobalISel] Fix -Wsign-compare on 32-bit -DLLVM_ENABLE_ASSERTIONS=on builds

llvm-svn: 360989

Revert Refactor constant evaluation of typeid(T) to track a symbolic type_info object rather than tracking the originating expression.

This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009)

llvm-svn: 360988

Revert [c++20] P1327R1: Support for typeid applied to objects of polymorphic class type in constant evaluation.

This reverts r360977 (git commit f51dc8d2f98f4029247552bc45ef53628ab3b6b9)

llvm-svn: 360987

[MC][PowerPC] Clean up PPCAsmBackend

Replace the member variable Target with Triple
Use Triple instead of TheTarget.getName() to dispatch on 32-bit/64-bit.
Delete redundant parameters

llvm-svn: 360986

Re-land: Add Clang shared library with C++ exports

Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.

This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.

llvm-svn: 360985

[ELF] Implement Dependent Libraries Feature

This patch implements a limited form of autolinking primarily designed to allow
either the --dependent-library compiler option, or "comment lib" pragmas (
https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in
C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically
add the specified library to the link when processing the input file generated
by the compiler.

Currently this extension is unique to LLVM and LLD. However, care has been taken
to design this feature so that it could be supported by other ELF linkers.

The design goals were to provide:

- A simple linking model for developers to reason about.
- The ability to to override autolinking from the linker command line.
- Source code compatibility, where possible, with "comment lib" pragmas in other
  environments (MSVC in particular).

Dependent library support is implemented differently for ELF platforms than on
the other platforms. Primarily this difference is that on ELF we pass the
dependent library specifiers directly to the linker without manipulating them.
This is in contrast to other platforms where they are mapped to a specific
linker option by the compiler. This difference is a result of the greater
variety of ELF linkers and the fact that ELF linkers tend to handle libraries in
a more complicated fashion than on other platforms. This forces us to defer
handling the specifiers to the linker.

In order to achieve a level of source code compatibility with other platforms
we have restricted this feature to work with libraries that meet the following
"reasonable" requirements:

1. There are no competing defined symbols in a given set of libraries, or
   if they exist, the program owner doesn't care which is linked to their
   program.
2. There may be circular dependencies between libraries.

The binary representation is a mergeable string section (SHF_MERGE,
SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES
(0x6fff4c04). The compiler forms this section by concatenating the arguments of
the "comment lib" pragmas and --dependent-library options in the order they are
encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs
sections with the normal mergeable string section rules. As an example, #pragma
comment(lib, "foo") would result in:

.section ".deplibs","MS",@llvm_dependent_libraries,1
         .asciz "foo"

For LTO, equivalent information to the contents of a the .deplibs section can be
retrieved by the LLD for bitcode input files.

LLD processes the dependent library specifiers in the following way:

1. Dependent libraries which are found from the specifiers in .deplibs sections
   of relocatable object files are added when the linker decides to include that
   file (which could itself be in a library) in the link. Dependent libraries
   behave as if they were appended to the command line after all other options. As
   a consequence the set of dependent libraries are searched last to resolve
   symbols.
2. It is an error if a file cannot be found for a given specifier.
3. Any command line options in effect at the end of the command line parsing apply
   to the dependent libraries, e.g. --whole-archive.
4. The linker tries to add a library or relocatable object file from each of the
   strings in a .deplibs section by; first, handling the string as if it was
   specified on the command line; second, by looking for the string in each of the
   library search paths in turn; third, by looking for a lib<string>.a or
   lib<string>.so (depending on the current mode of the linker) in each of the
   library search paths.
5. A new command line option --no-dependent-libraries tells LLD to ignore the
   dependent libraries.

Rationale for the above points:

1. Adding the dependent libraries last makes the process simple to understand
   from a developers perspective. All linkers are able to implement this scheme.
2. Error-ing for libraries that are not found seems like better behavior than
   failing the link during symbol resolution.
3. It seems useful for the user to be able to apply command line options which
   will affect all of the dependent libraries. There is a potential problem of
   surprise for developers, who might not realize that these options would apply
   to these "invisible" input files; however, despite the potential for surprise,
   this is easy for developers to reason about and gives developers the control
   that they may require.
4. This algorithm takes into account all of the different ways that ELF linkers
   find input files. The different search methods are tried by the linker in most
   obvious to least obvious order.
5. I considered adding finer grained control over which dependent libraries were
   ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this
   is not necessary: if finer control is required developers can fall back to using
   the command line directly.

RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html.

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

llvm-svn: 360984

[X86] Support .reloc *, R_{386,X86_64}_NONE, *

This can be used to create references among sections. When --gc-sections
is used, the referenced section will be retained if the origin section
is retained.

See R_MIPS_NONE (D13659), R_ARM_NONE (D61992), R_AARCH64_NONE (D61973) for similar changes.

Reviewed By: rnk

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

llvm-svn: 360983

[GWP-ASan] Fixed issue with c++ standard library dependency.

Summary:
Removed dependency on c++ standard library. Some supporting allocators (namely Scudo on Fuchsia, and shortly, scudo standalone) has a hard requirement of no c++stdlib.

This patch updates the build system so that we don't have any c++ stdlib dependencies. It also will conveniently fix a racy build-order bug discrepency between GWP-ASan and libc++.

Reviewers: phosek, morehouse

Reviewed By: phosek, morehouse

Subscribers: kubamracek, mgorny, cryptoad, #sanitizers, llvm-commits, beanz, smeenai, vitalybuka

Tags: #sanitizers, #llvm

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

llvm-svn: 360982

[AArch64] Support .reloc *, R_AARCH64_NONE, *

Summary:
This can be used to create references among sections. When --gc-sections
is used, the referenced section will be retained if the origin section
is retained.

Reviewed By: peter.smith

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

llvm-svn: 360981

[ARM] Support .reloc *, R_ARM_NONE, *

R_ARM_NONE can be used to create references among sections. When
--gc-sections is used, the referenced section will be retained if the
origin section is retained.

Add a generic MCFixupKind FK_NONE as this kind of no-op relocation is
ubiquitous on ELF and COFF, and probably available on many other binary
formats. See D62014.

Reviewed By: peter.smith

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

llvm-svn: 360980

[LFTR] Strengthen assertions in genLoopLimit [NFCI]

llvm-svn: 360978

[c++20] P1327R1: Support for typeid applied to objects of polymorphic
class type in constant evaluation.

llvm-svn: 360977

[IndVars] Don't reimplement Loop::isLoopInvariant [NFC]

Using dominance vs a set membership check is indistinguishable from a compile time perspective, and the two queries return equivelent results.  Simplify code by using the existing function.

llvm-svn: 360976

Move symbol resolution code out of SymbolTable class.

This is the last patch of the series of patches to make it possible to
resolve symbols without asking SymbolTable to do so.

The main point of this patch is the introduction of
`elf::resolveSymbol(Symbol *Old, Symbol *New)`. That function resolves
or merges given symbols by examining symbol types and call
replaceSymbol (which memcpy's New to Old) if necessary.

With the new function, we have now separated symbol resolution from
symbol lookup. If you already have a Symbol pointer, you can directly
resolve the symbol without asking SymbolTable to do that.

Now that the nice abstraction become available, I can start working on
performance improvement of the linker. As a starter, I'm thinking of
making --{start,end}-lib faster.

--{start,end}-lib is currently unnecessarily slow because it looks up
the symbol table twice for each symbol.

 - The first hash table lookup/insertion occurs when we instantiate a
   LazyObject file to insert LazyObject symbols.

 - The second hash table lookup/insertion occurs when we create an
   ObjFile from LazyObject file. That overwrites LazyObject symbols
   with Defined symbols.

I think it is not too hard to see how we can now eliminate the second
hash table lookup. We can keep LazyObject symbols in Step 1, and then
call elf::resolveSymbol() to do Step 2.

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

llvm-svn: 360975

Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

llvm-svn: 360974

Revert r360946 "Add Clang shared library with C++ exports"

It breaks LLVM_ENABLE_PIC=OFF builds, and it's not clear
if the object library approach doesn't impact the normal
clang binary.

llvm-svn: 360973

[LFTR] Factor out a helper function for readability purpose [NFC]

llvm-svn: 360972

[Docs] Fix headings in remote debugging

Add the proper headings instead of using just a bold font. Also add the
local ToC.

llvm-svn: 360971

[CodeMetrics]  Don't let extends of i1 be free.

getUserCost() currently returns TCC_Free for any extend of a compare (i1)
result. It seems this is only true in a limited number of cases where for
example two compares are chained. Even in those types of cases it seems
unlikely that they are generally free, while they may be in some cases.

This patch therefore removes this special handling of cast of i1. No tests
are failing because of this.

If some target want the old behavior, it could override getUserCost().

Review: Hal Finkel, Chandler Carruth, Evgeny Astigeevich, Simon Pilgrim,
        Ulrich Weigand
https://reviews.llvm.org/D54742/new/

llvm-svn: 360970

Fix broken test case.

EXPECT_EQ takes two arguments, not a single expression that evaluates to bool.

llvm-svn: 360969

Clarify comments on helpers used by LFTR [NFC]

I'm slowly wrapping my head around this code, and am making comment improvements where I can.

llvm-svn: 360968

[Docs] Remove architectures from feature matrix

This is outdated, there's a bunch of architectures missing. If we want
them to be part of this table they should be a separate row anyway.

llvm-svn: 360967

[CommandInterpreter] Accept blanks after `all` or [0-9]+ for bt.

Previously "bt all    " would've failed as the regex didn't match
them.

Over the shoulder review by Jonas Devlieghere.

<rdar://problem/50824935>

llvm-svn: 360966

[SystemZ]  Bugfix in SystemZTargetLowering::combineIntDIVREM()

Make sure to not unroll a vector division/remainder (with a constant splat
divisor) after type legalization, since the scalar type may then be illegal.

Review: Ulrich Weigand
https://reviews.llvm.org/D62036

llvm-svn: 360965

[Docs] Unify sidebar padding

Unify the padding across list items and the list header.

llvm-svn: 360964

Revert r360859: "Reland r360771 "[MergeICmps] Simplify the code.""

It caused PR41917.

llvm-svn: 360963

Convert PointerUnion to a variadic template.

Summary:
Rather than duplicating code between PointerUnion, PointerUnion3, and
PointerUnion4 (and missing things from the latter cases, such as some of the
DenseMap support and operator==), convert PointerUnion to a variadic template
that can be used as a union of any number of pointers.

(This doesn't support PointerUnion<> right now. Adding a special case for that
would be possible, and perhaps even useful in some situations, but it doesn't
seem worthwhile until we have a concrete use case.)

Reviewers: dblaikie

Subscribers: dexonsmith, kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 360962

[Tests] Consolidate more lftr tests

These are all of the ones involving the same data layout string.  Remainder take a bit more consideration, but at least everything can be auto-updated now.

llvm-svn: 360961

[X86][AsmParser] Add mnemonics missed in r360954.

These are valid Jcc, but aren't based on the EFLAGS condition codes (Intel 64
and IA-32 Architetcures Software Developer's Manual Vol. 1, Appendix B). These
are covered in clang/test, but not llvm/test.

llvm-svn: 360960

HWASan exception support.

Summary:
Adds a call to __hwasan_handle_vfork(SP) at each landingpad entry.

Reusing __hwasan_handle_vfork instead of introducing a new runtime call
in order to be ABI-compatible with old runtime library.

Reviewers: pcc

Subscribers: kubamracek, hiraditya, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

llvm-svn: 360959

[sanitizer] Don't generate "failed to intercept" constants for each function

llvm-svn: 360958

[Tests] Expand basic lftr coverage

Newly written tests to cover the simple cases.  We don't appear to have broad coverage of this transform anywhere.

llvm-svn: 360957

Slightly update the macOS part of status.rst to be less out-of-date.

llvm-svn: 360956

Revert r358069 "Discard debuginfo for object files empty after GC"

The change broke some scenarios where debug information is still
needed, although MarkLive cannot see it, including the
Chromium/Android build. Reverting to unbreak that build.

llvm-svn: 360955

[X86][AsmParser] Ignore "short" even harder in Intel syntax ASM.

In Intel syntax, it's not uncommon to see a "short" modifier on Jcc conditional
jumps, which indicates the offset should be a "short jump" (8-bit immediate
offset from EIP, -128 to +127). This patch expands to all recognized Jcc
condition codes, and removes the inline restriction.

Clang already ignores "jmp short" in inline assembly. However, only "jmp" and a
couple of Jcc are actually checked, and only inline (i.e., not when using the
integrated assembler for asm sources). A quick search through asm-containing
libraries at hand shows a pretty broad range of Jcc conditions spelled with
"short."

GAS ignores the "short" modifier, and instead uses an encoding based on the
given immediate. MS inline seems to do the same, and I suspect MASM does, too.
NASM will yield an error if presented with an out-of-range immediate value.

Example of GCC 9.1 and MSVC v19.20, "jmp short" with offsets that do and do not
fit within 8 bits: https://gcc.godbolt.org/z/aFZmjY

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

llvm-svn: 360954

[X86][AsmParser] Rename "ConditionCode" variable to "ConditionPredicate".

This better matches the verbiage in Intel documentation, and should help avoid
confusion between these two different kinds of values, both of which are parsed
from mnemonics.

llvm-svn: 360953

[X86] Deduplicate symbol lowering logic, NFC

Summary:
This refactors four pieces of code that create SDNodes for references to
symbols:
- normal global address lowering (LEA, MOV, etc)
- callee global address lowering (CALL)
- external symbol address lowering (LEA, MOV, etc)
- external symbol address lowering (CALL)

Each of these pieces of code need to:
- classify the reference
- lower the symbol
- emit a RIP wrapper if needed
- emit a load if needed
- add offsets if needed

I think handling them all in one place will make the code easier to
maintain in the future.

Reviewers: craig.topper, RKSimon

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 360952

Remove unneeded alignment spec from builtin_FUNCTION.cpp test

llvm-svn: 360951

Emit global variables as S_CONSTANT records for codeview debug info.

Summary:
This emits S_CONSTANT records for global variables.
Currently this emits records for the global variables already being tracked in the
LLVM IR metadata, which are just constant global variables; we'll also want S_CONSTANTs
for static data members and enums.

Related to https://bugs.llvm.org/show_bug.cgi?id=41615

Reviewers: rnk

Subscribers: aprantl, hiraditya, llvm-commits, thakis

Tags: #llvm

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

llvm-svn: 360948

Fix failing source location test on Windows

llvm-svn: 360947

Add Clang shared library with C++ exports

Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.

This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.

Reviewers: tstellar, winksaville

Subscribers: mgorny, cfe-commits

Tags: #clang

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

llvm-svn: 360946

[Target] Stop linking against lldbPluginObjCLanguage

llvm-svn: 360945

XFAIL test for new GCC version

llvm-svn: 360944

Fix PCC test failures for source location builtins

llvm-svn: 360943

[CodeGen] Fixed de-optimization of legalize subvector extract

The recent introduction of v3i32 etc as an MVT, and its use in AMDGPU
3-dword memory instructions, caused a de-optimization problem for code
with such a load that then bitcasts via vector of i8, because v12i8 is
not an MVT so it legalizes the bitcast by widening it.

This commit adds the ability to widen a bitcast using extract_subvector
on the result, so the value does not need to go via memory.

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

Change-Id: Ie4abb7760547e54a2445961992eafc78e80d4b64
llvm-svn: 360942

[WebAssembly] Move code and data section generation to finalizeContent. NFC.

Previously these sections were being generated during their
constructors.  This moves the work to finalizeContent, and also does
the same for the relocation sections because their contents depends
on the final layout too.

This change is part of a larger refactor to how we deal with synthetic
sections: https://reviews.llvm.org/D61811

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

llvm-svn: 360941

[WebAssembly] Don't generate empty type sections.

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

llvm-svn: 360940

[clang/test] Add missing dependency on llvm-cxxfilt.

This tool is needed by clang/test/CodeGen/Output/ppc-mmintrin.c.

llvm-svn: 360939

Reland "[Clang][PP] Add the __FILE_NAME__ builtin macro"

This relands commit rL360833 which caused issues on Win32
bots due to path handling/normalization differences. Now
this uses `sys::path::filename` which should handle
additional edge cases on Win32.

Original commit:

"[Clang][PP] Add the __FILE_NAME__ builtin macro"

This patch adds the __FILE_NAME__ macro that expands to the
last component of the path, similar to __FILE__ except with
a guarantee that only the last path component (without the
separator) will be rendered.

I intend to follow through with discussion of this with WG14
as a potential inclusion in the C standard or failing that,
try to discuss this with GCC developers since this extension
is desired by GCC and Clang users/developers alike.

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

llvm-svn: 360938

Implement __builtin_LINE() et. al. to support source location capture.

Summary:
This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation).

With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible.

Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong

Reviewed By: rsmith

Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits

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

llvm-svn: 360937

[Tests] More consolidation of lftr tests

llvm-svn: 360936

[Test] Remove a bunch of cruft from a test

This test hadn't been fully reduced, so do so.

llvm-svn: 360935

[Tests] Start consolidating lftr tests into a single file

llvm-svn: 360934

[Tests] Autogen the last lftr test

llvm-svn: 360933

[Tests] Autogen a few more lftr tests for readability

llvm-svn: 360932

[Tests] Autogen a few lftr test in preparation for merging

llvm-svn: 360931

Factor out switch statement into a helper function (NFC)

This addresses post-commit review feedback for https://reviews.llvm.org/D62015.

llvm-svn: 360930

Make sure GetObjectDescription falls back to the Objective-C runtime.

This fixes an unintended regression introduced by
https://reviews.llvm.org/D61451 by making sure the Objective-C runtime
is also tried when the "correct" language runtime failed to return an
object description.

rdar://problem/50791055

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

llvm-svn: 360929

[NFC][InstSimplify] Update fast-math.ll tests I botched in r360808.

These were new tests I added in r360808. I made a mistake while converting the exisiting binary FNeg test into the new unary FNeg tests. Correct that.

llvm-svn: 360928

[TSan][libdispatch] Use FileCheck's --implicit-check-not=...

Use FileCheck's --implicit-check-not='ThreadSanitizer' which increases
the strictness of our tests a bit. NFC.

```
CHECK: start
CHECK-NOT: ThreadSanitizer
CHECK: done
```

With --implicit-check-not, the above is turned into:

```
CHECK-NOT: ThreadSanitizer
CHECK: start
CHECK-NOT: ThreadSanitizer
CHECK: done
CHECK-NOT: ThreadSanitizer
```

llvm-svn: 360927

[ORC] Change handling for SymbolStringPtr tombstones and empty keys.

SymbolStringPtr used to use nullptr as its empty value and (since it performed
ref-count operations on any non-nullptr) a pointer to a special pool-entry
instance as its tombstone.

This commit changes the scheme to use two invalid pointer values as the empty
and tombstone values, and broadens the ref-count guard to prevent ref-counting
operations from being performed on these pointers. This should improve the
performance of SymbolStringPtrs used in DenseMaps/DenseSets, as ref counting
operations will no longer be performed on the tombstone.

llvm-svn: 360925

[X86] Stop implicitly enabling avx512vl when avx512bf16 is enabled.

Previously we were doing this so that the 256 bit selectw builtin could be used in the implementation of the 512->256 bit conversion intrinsic.

After this commit we now use a masked convert builtin that will emit the intrinsic call and the 256-bit select from custom code in CGBuiltin. Then the header only needs to call that one intrinsic.

llvm-svn: 360924

[InstCombine] add tests for shuffle of insert subvectors; NFC

llvm-svn: 360923

Update comments on enums

llvm-svn: 360922

Fix typos in comment.

llvm-svn: 360921

Move TraversalKind enum to ast_type_traits

Summary:
Make it usable outside of ASTMatchFinder.  This will make it possible to
use this enum to control whether certain implicit nodes are skipped
while AST dumping for example.

Reviewers: klimek, aaron.ballman

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 360920