[SLP] ScalarizationOverheadBuilder - demand all elements for scalarization if the extraction index is unknown / out of bounds

Workaround for a chromium bug reported on D134605 - test case will be added later

We are already using the Co-author-by git tag, but don't have documentation in
our developer policy about it. Fix that.

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

Both LLD and GNU ld write global/static variables to the COFF symbol
table with `IMAGE_SYM_TYPE_NULL` and `IMAGE_SYM_DTYPE_NULL` type. Map
these symbols as 'Data' type in the symtab to allow these symbols to be
used in expressions and printable.

Reviewed By: labath, DavidSpickett

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

Forwarder exports do not point to a real function or variable. Instead
they point to a string describing which DLL and symbol to forward to.
Any imports which uses them will be redirected by the loader
transparently. These symbols do not have much use in LLDB, but keep them
just in case someone find it useful. Also set a synthesized name with
the forwarder string for informational purpose.

Reviewed By: labath

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

Reviewed By: labath

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

If a symbol is the same as an export symbol, mark it as 'Additional' to
prevent the duplicated symbol from being repeated in some commands (e.g.
`disas -n func`). If the RVA is the same but exported with a different
name, only synchronize the symbol types.

Reviewed By: labath

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

- Skip dummy/invalid export symbols.
- Make the export ordinal of export symbols visible when dumping the
  symtab.
- Stop setting the 'Debug' flag and set the 'External' flag instead to
  better match the meaning of export symbols.
- Try to guess the type (code vs data) of the symbol from section flags.

Reviewed By: labath

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

This reimplements `ObjectFilePECOFF::ParseSymtab` to replace the manual
data extraction with what `COFFObjectFile` already provides. Also use
`SymTab::AddSymbol` instead of resizing the SymTab then assigning each
elements afterwards.

Previously, ParseSymTab loads symbols from both the COFF symbol table
and the export table, but if there are any entries in the export table,
it overwrites all the symbols already loaded from the COFF symbol table.
Due to the change to use AddSymbols, this no longer happens, and so the
SymTab now contains all symbols from both tables as expected.

The export symbols are now ordered by ordinal, instead of by the name
table order.

In its current state, it is possible for symbols in the COFF symbol
table to be duplicated by those in the export table. This behaviour will
be modified in a separate change.

Reviewed By: labath

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

Defines LoongArch registers for getExceptionPointerRegister() and
getExceptionSelectorRegister().

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

Since version 0.10 we've:

* Added support for viewing/editing bytecode files

GetErrcMessages.cmake module makes use of cmake's try_run which by
default builds its sources in debug mode unless configured with
CMAKE_TRY_COMPILE_CONFIGURATION. Debug builds on Windows sometimes fail
when appropraite DLLs are not included in path. Also on Windows on Arm
machines debug builds sometimes fail to link the correct debug DLLs.

To fix this I am setting CMAKE_TRY_COMPILE_CONFIGURATION to active build
configuration of currently configured LLVM project. This makes sure we
select same build type for try_run/try_compile cmake modules as
currently configured LLVM project.

Reviewed By: zero9178

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

Fixes #57572

Generally LICM pass is responsible for sinking out code that calculates
invariant address inside loop as it only needed to be calculated once.
But in rare case it does not happen we will not be vectorizing the
loop.

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

Reviewed By: RKSimon

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

These instructions are flag setting so the ptest is redundant, the
TableGen class wasn't setting the element size for the predicate causing
the checks in AArch64InstrInfo::optimizePTestInstr to fail.

The 'RUN' command was missing the input file argument.

Normal compilation doesn't care about tracking references,
and shouldn't pay the compilation time cost.

These look like they were copy/pasted from vfabs-vp.ll

Reviewed By: eopXD

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

This reverts commit bce64167.

The workaround is unneeded after 7dac9f4e.

This allows hover documentation to show up in the vscode extension.

The existing thrd_once function has been refactored so that the
implementation can be shared between thrd_once and pthread_once
functions.

Reviewed By: michaelrj

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

This was missed when bytecode support was originally added.

This allows for go-to-def on the a `let` field to resolve to the definition
of the base class. This is kind of like how C++ works with go-to-def
from use->def->decl, with the decl in this case being the base definition
of the field.

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

This provides hover information for classes, defs, fields, and template
arguments. Like PDLL, this pulls documentation from the source code
when hovering over fields and records.

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

This is extremely useful for language tooling as it allows
for providing go-to-def/find-references/etc. for many
more situations than what is currently possible.

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

Reviewed By: reames

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

There are many files that needs to be updated when you
bump the version of LLVM. This script tries to automate
that in order to make the release managers job easier.

Reviewed By: kwk, hans, ldionne

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

Currently, lowering is promoting main program array and character
variables that are not saved into static memory.

This causes issues with equivalence initial value images because
semantics is relying on IsSaved to build the initial value of variables
in static memory. It seems more robust to have IsSaved be the place
deciding if a variable needs to be in static memory (except for common
block members).

Move the logic to decide if a main program variable must be in static
memory into evaluate::IsSaved and add two options to semantics to
replace the llvm options that were used in lowering:
 - SaveMainProgram (off by default): save all main program variables.
 - SaveBigMainProgramVariables (on by default): save all main program
   variables that are bigger than 32 bytes.

The first options is required to run a few old programs that expect all
main program variables to be in bss (and therefore zero initialized).

The second option is added to allow performance testing: placing big
arrays in static memory seems a sane default to avoid blowing up the
stack with old programs that define big local arrays in the main
program, but since it is easier to prove that an alloca does not
escape/is not modified by calls, keeping big arrays on the stack could
yield improvements.

The logic of SaveBigMainProgramVariables is slightly changed compared to what
it was doing in lowering. The old code was placing all arrays and all
explicit length characters in static memory.
The new code is placing everything bigger than 32 bytes in static
memory. This has the advantages of being a simpler logic, and covering
the cases of scalar derived type with big array components or many
components. Small strings and arrays are now left on the stack (after
all, a character(1) can fit in register).

Note: I think it could have been nicer to add a single "integer" option
to set a threshold to place main program variables in static memory so
that this can be fine tuned by the drivers (SaveMainProgram would be
implemented by setting it to zero). But the language feature options are
not meant to carry integer options. Extending it for this seems an
overkill precedent, and placing it in SemanticsContext is weird (it is
a too low level option to be a bare member of SemanticsContext in my
opinion). So I just rolled my own dices and picked 32 for the sake of
simplicity.

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

This reverts commit 6e491c48.
There are missed changes in flang.

This is slightly cleaner.

The next patch will require more generic name.

The issue is not confirmened, but tests can stay.

Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.

This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.

No functional changes.

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

After https://reviews.llvm.org/D134461, Clang will diagnose a warning if
trying to deference void pointers in C mode. However, this causes a lot
of noises when compiling a 5.19.11 Linux kernel.

This patch reduces the warning by marking deferencing void pointers in
unevaluated context OK, like `sizeof(*void_ptr)`, `typeof(*void_ptr)`
and etc.

Fixes https://github.com/ClangBuiltLinux/linux/issues/1720



Signed-off-by: Jun Zhang <jun@junz.org>

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