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

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

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

While vectors use insertelement, structs and arrays should use
insertvalue.

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

We can't use an IR input once the relevant constant expressions
are no longer supported. Use a bitcode file instead, which will
be auto-upgraded (the whole point of this code...)

Refactor static functions into class methods so they have access to TII, MRI
etc.

Call ConstantFoldUnaryInstruction() instead, to only produce a
result if it folds.

Interpret MD_pcsections in AsmPrinter emitting the requested metadata to
the associated sections. Functions and normal instructions are handled.

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

Propagate (most) PC sections metadata to MachineInstr when GlobalISel is
doing instruction selection.

This change results in support for architectures using GlobalISel (such
as -O0 with AArch64). Not all instructions may be supported yet, and
requires further target-specific handling (such as done for AArch64
pseudo-atomics). Expanding supported instructions is planned on a
case-by-case basis and new use cases for PC sections metadata.

Reviewed By: vitalybuka

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

When expanding IR atomics to target-specific atomics, copy all
!pcsections Metadata to expanded atomics automatically.

Reviewed By: vitalybuka

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

Propagate PC sections metadata to MachineInstr when FastISel is doing
instruction selection.

Reviewed By: vitalybuka

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

Don't create fneg expressions unless explicitly requested by IR or
bitcode.

In many places DebugLoc and PCSections metadata are just copied along to
propagate them through MachineInstrs. Simplify doing so by bundling them
up in a MIMetadata class that replaces the DebugLoc argument to most
BuildMI() variants.

The DebugLoc-only constructors allow implicit construction, so that
existing usage of `BuildMI(.., DL, ..)` works as before, and the rest of
the codebase using BuildMI() does not require changes.

NFC.

Reviewed By: vitalybuka

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

Add a new entry to SDNodeExtraInfo to propagate PCSections through
SelectionDAG.

Reviewed By: vitalybuka

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

Simplify instruction selection patterns for mad/mac:
- Use any_fmad consistently to make it clear that all patterns treat
  fmad and AMDGPUfmad_ftz identically.
- For mad, put the patterns on the instruction definitions. For mac the
  patterns are still out-of-line because we want to set AddedComplexity
  and to have special handling of the source modifiers.

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

Document (in comments) the optional fourth "stride" argument to the
sequence operator, which was added in svn r157416.

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

Use ConstantFoldUnaryOpOperand() instead. Also make the code below
robust against non-instruction users, just in case it doesn't fold.

We can use `getValueOrCreateConstantIndexOp` instead.

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

This file is auto-generated, it's a bit confusing for the maintainers to have it
in tree while it shouldn't be modified *and* already have a rule to be
generated.

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

Introduce mlir::hasEffect and refactor existing usage to use utility.
NFC.

Reviewed By: rriddle, mehdi_amini

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

Reviewed By: LuoYuanke

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

Bug: An assertion fails:

    Assertion failed: isa<To>(Val) && "cast<Ty>() argument of incompatible type!",
    file C:\Users\<user>\prog\llvm\llvm-git-lld-bug\llvm\include\llvm/Support/Casting.h, line 578

Bug is triggered, if

    - a map file is requested with /MAP, and
    - Architecture is ARMv7, Thumb, and
    - a relative jump (branch instruction) is greater than 16 MiB (2^24)

The reason for the Bug is:

    - a Thunk is created for the jump
    - a Symbol for the Thunk is created
        - of type `DefinedSynthetic`
        - in file `Writer.cpp`
        - in function `getThunk`
    - the Symbol has no name
    - when creating the map file, the name of the Symbol is queried
    - the function `Symbol::computeName` of the base class `Symbol`
      casts the `this` pointer to type `DefinedCOFF` (a derived type),
      but the acutal type is `DefinedSynthetic`
    - The in the llvm::cast an assertion fails

Changes:

- Modify regression test to trigger this bug
- Give the symbol pointing to the thunk a name, to fix the bug
- Add assertion, that only DefinedCOFF symbols are allowed to have an
  empty name, when the constructor of the base class Symbol is executed

Reviewed By: rnk

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

Fix the is_binutils_lto_supported() function to handle missing
executables gracefully.  Currently, the function does not catch
exceptions from subprocess.Popen() and therefore causes lit to crash
if config.gold_executable does not specify a valid executable:

```
lit: /usr/lib/python3.11/site-packages/lit/TestingConfig.py:136: fatal: unable to parse config file '/tmp/portage/sys-libs/compiler-rt-
15.0.0/work/compiler-rt/test/lit.common.cfg.py', traceback: Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/lit/TestingConfig.py", line 125, in load_from_path
    exec(compile(data, path, 'exec'), cfg_globals, None)
  File "/tmp/portage/sys-libs/compiler-rt-15.0.0/work/compiler-rt/test/lit.common.cfg.py", line 561, in <module>
    if is_binutils_lto_supported():
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/portage/sys-libs/compiler-rt-15.0.0/work/compiler-rt/test/lit.common.cfg.py", line 543, in is_binutils_lto_supported
    ld_cmd = subprocess.Popen([exe, '--help'], stdout=subprocess.PIPE, env={'LANG': 'C'})
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 1022, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.11/subprocess.py", line 1899, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'GOLD_EXECUTABLE-NOTFOUND'
```

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

This patch uses roundeven/roundevenf of libm to fold RoundEvenOp of constant.

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

some regular files(e.g. files have no shebang and no execute
bit in source dir) are wrongly assigned an execution permission,
such as scanview.css and ear.c from libscanbuild, which is
unnecessary and introduces warnings in some envs.

Reviewed By: MaskRay, phosek

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

This patch adds constant folder for CosOp which only supports single and double precision floating-point.

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

We should only use 'auto' in case we can know the type from the right
hand side of the expression. Also we need keep '*' around if the type is
a pointer actually. Few uses of 'auto' in SemaCoroutine.cpp and
CGCoroutine.cpp violates the rule. This commit tries to fix it.

Details:

Currently CodeGenPrepare is very time consuming in handling big functions.

Old Algorithm :
It iterate each BB in function, and go on handle very instructions in BB.
Due to some instruction optimizations may affect the BBs' dominate tree.
The old logic will re-iterate and try optimize for each BB.

Suppose we have a big function with 20000 BBs, If we handled the last BB
with fine tuning the dominate tree. We need totally re-iterate and try optimize
the 20000 BBs from the beginning.

The Complex is near N!

And we really encounter somes big tests (> 20000 BBs) that cost more than 30
mins in this pass. (Debug version compiler will cost 2 hours here)

What this patch do for huge function ?
It mainly changes the iteration way for optimization.

1 We do optimizeBlock for each BB (that is same with old way).
And, in the meaning time, If BB is changed/updated in the optimization, it will
be put into FreshBBs (try do optimizeBlock again).
The new created BB at previous iteration will also put into FreshBBs.

2 For the BBs which not updated at previous iteration, we directly skip it.
Strictly speaking, here may miss some opportunity, but the probability is very
small.

3 For Instructions in single BB, we do optimizeInst for each instruction.
If optimizeInst change the instruction dominator in this BB, rather than break
and go back to optimize the first BB (the old way), we directly iterate
instructions (to do optimizeInst) in this updated BB again (the new way).

What this patch do for small/normal (not huge) function ?
It is same with the Old Algorithm. (NFC)

Reviewed By: LuoYuanke

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

This manifests as an msan error because we check the value of `es`, but it's actually uninitialized because we mistakenly set `ss` twice.

Summary:
Previously the new driver crashed when using `-fsyntax-only` which
required a work-around in one of the test files. This was not properly
updated when it was fixed for the new driver. This patch fixes the test
and also adjusts a missing boolean check.