1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 20:23:11 +01:00
Commit Graph

823 Commits

Author SHA1 Message Date
Nikita Popov
c2a36153e1 [ConstantFold] Fix GEP of GEP fold with opaque pointers
This was previously combining indices even though they operate on
different types. For non-opaque pointers, the condition is
automatically satisfied based on the pointer types being equal.
2021-07-23 23:56:41 +02:00
Pirama Arumuga Nainar
987b8f791e [NewPM] Add CrossDSOCFI pass irrespective of LTO optimization level
This pass is not an optimization and is needed for CFI functionality
(cross-dso verification).

Differential Revision: https://reviews.llvm.org/D106699
2021-07-23 14:13:12 -07:00
Arthur Eubanks
d577e2748f [NewPM] Print pre-transformation IR name in --print-after-all
Sometimes a transformation can change the name of some IR (e.g. an SCC
with functions added/removed). This can be confusing when debug logging
doesn't match the post-transformation name. The specific example I came
across was that --print-after-all said the inliner was working on an SCC
that only contained one function, but calls in multiple functions were
getting inlined. After all inlining, the current SCC only contained one
function.

Piggyback off of the existing logic to handle invalidated IR +
--print-module-scope. Simply always store the IR description and use
that.

Reviewed By: jamieschmeiser

Differential Revision: https://reviews.llvm.org/D106290
2021-07-20 10:20:10 -07:00
Arthur Eubanks
23b99bd6ce [NewPM][opt] Add -debug-pass-manager=quiet to not print analysis info
Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D106307
2021-07-19 15:08:26 -07:00
Arthur Eubanks
0b315633ca [NewPM] Bail out of devirtualization wrapper if the current SCC is invalidated
The specific case that triggered this was when inlining a recursive
internal function into itself caused the recursion to go away, allowing
the inliner to mark the function as dead. The inliner marks the SCC as
invalidated but does not provide a new SCC to continue with.

This matches the implementations of ModuleToPostOrderCGSCCPassAdaptor
and CGSCCPassManager.

Fixes PR50363.

Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D106306
2021-07-19 15:07:30 -07:00
Chuanqi Xu
ca13ea7edf [Coroutines] Run coroutine passes by default
This patch make coroutine passes run by default in LLVM pipeline. Now
the clang and opt could handle IR inputs containing coroutine intrinsics
without special options.
It should be fine. On the one hand, the coroutine passes seems to be stable
since there are already many projects using coroutine feature.
On the other hand, the coroutine passes should do nothing for IR who doesn't
contain coroutine intrinsic.

Test Plan: check-llvm

Reviewed by: lxfind, aeubanks

Differential Revision: https://reviews.llvm.org/D105877
2021-07-15 14:33:40 +08:00
Arthur Eubanks
78dcef41e1 [NewPM][SimpleLoopUnswitch] Add option to not trivially unswitch
To help with debugging non-trivial unswitching issues.

Don't care about the legacy pass, nobody is using it.

If a pass's string params are empty (e.g. "simple-loop-unswitch"), don't
default to the empty constructor for the pass params. We should still
let the parser take care of it in case the parser has its own defaults.

Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D105933
2021-07-13 16:09:42 -07:00
Bjorn Pettersson
9033ba7995 [NewPM] Rename 'unswitch' to 'simple-loop-unswitch' in PassRegistry
It is confusing to have two ways of specifying the same pass
('simple-loop-unswitch' and 'unswitch'). This patch replaces
'unswitch' by 'simple-loop-unswitch' to get a unique identifier.

Using 'simple-loop-unswitch' instead of 'unswitch' also has the
advantage of matching how the pass is named in DEBUG_TYPE etc. So
this makes it a bit more consistent how we refer to the pass in
options such as -passes, -print-after and -debug-only.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D105628
2021-07-09 09:47:33 +02:00
Bjorn Pettersson
8be96b95c4 [NewPM] Consistently use 'simplifycfg' rather than 'simplify-cfg'
There was an alias between 'simplifycfg' and 'simplify-cfg' in the
PassRegistry. That was the original reason for this patch, which
effectively removes the alias.

This patch also replaces all occurrances of 'simplify-cfg'
by 'simplifycfg'. Reason for choosing that form for the name is
that it matches the DEBUG_TYPE for the pass, and the legacy PM name
and also how it is spelled out in other passes such as
'loop-simplifycfg', and in other options such as
'simplifycfg-merge-cond-stores'.

I for some reason the name should be changed to 'simplify-cfg' in
the future, then I think such a renaming should be more widely done
and not only impacting the PassRegistry.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D105627
2021-07-09 09:47:03 +02:00
Bjorn Pettersson
6cdbedb38b [NewPM] Handle passes with params in -print-before/-print-after
To support options like -print-before=<pass> and -print-after=<pass>
the PassBuilder will register PassInstrumentation callbacks as well
as a mapping between internal pass class names and the pass names
used in those options (and other cmd line interfaces). But for
some reason all the passes that takes options where missing in those
maps, so for example "-print-after=loop-vectorize" didn't work.

This patch will add the missing entries by also taking care of
function and loop passes with params when setting up the class to
pass name maps.

One might notice that even with this patch it might be tricky to
know what pass name to use in options such as -print-after. This
because there only is a single mapping from class name to pass name,
while the PassRegistry currently is a bit messy as it sometimes
reuses the same class for different pass names (without using the
"pass with params" scheme, or the pass-name<variant> syntax).

It gets extra messy in some situations. For example the
MemorySanitizerPass can run like this (with debug and print-after)
  opt -passes='kmsan' -print-after=msan-module -debug-only=msan
The 'kmsan' alias for 'msan<kernel>' is just confusing as one might
think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still
just 'msan'). And since the module pass version of the pass adds
a mapping from 'MemorySanitizerPass' to 'msan-module' one need to
use 'msan-module' in the print-before and print-after options.

Reviewed By: ychen

Differential Revision: https://reviews.llvm.org/D105006
2021-07-09 09:27:37 +02:00
Yuanfang Chen
6c6f53ed0f Add AddDiscriminatorsPass to NPM default O0 pipeline
AddDiscriminatorsPass is in Legacy PM's O0 pipeline. This patch did the same
for NPM O0 pipeline.

Reviewed By: aeubanks, MaskRay

Differential Revision: https://reviews.llvm.org/D105650
2021-07-08 16:37:20 -07:00
Nikita Popov
6203a57d08 [OpaquePtr] Support opaque pointers in intrinsic type check
This adds support for opaque pointers in intrinsic type checks
of IIT kind Pointer and PtrToElt.

This is less straight-forward than it might initially seem, because
we should only accept opaque pointers here in --force-opaque-pointers
mode. Otherwise, there would be more than one valid type signature
for a given intrinsic name.

Differential Revision: https://reviews.llvm.org/D105155
2021-07-01 18:26:41 +02:00
Nikita Popov
8e01de7107 [Test] Regenerate test checks (NFC)
Make these follow the update_test_checks.py format.
2021-06-29 23:44:56 +02:00
Duncan P. N. Exon Smith
b2d9b100f4 OpaquePtr: Support i32** with --force-opaque-pointers
4506f614cb6983a16d117cf77a968608e66d7a5c fixed parsing of textual IR to
reject `ptr*`, but broke the auto-conversion of `i32**` to `ptr` with
`--force-opaque-pointers`.

Get that working again by refactoring LLParser::parseType to only send
`ptr`-spelled pointers into the type suffix logic when it's the return
of a function type. This also rejects `ptr addrspace(3) addrspace(2)`,
which 1e6303e60ca5af4fbe7ca728572fd65666a98271 invadvertently started
accepting. Just the default top-level error message for the
double-addrspace since I had trouble thinking of something nice;
probably it's fine as is (it doesn't look valid the way that `ptr*`
does).

Differential Revision: https://reviews.llvm.org/D105146
2021-06-29 14:10:29 -07:00
Nikita Popov
a2c6bb600a [OpaquePtr] Support forward references in textual IR
Currently, LLParser will create a Function/GlobalVariable forward
reference based on the desired pointer type and then modify it when
it is declared. With opaque pointers, we generally do not know the
correct type to use until we see the declaration.

Solve this by creating the forward reference with a dummy type, and
then performing a RAUW with the correct Function/GlobalVariable when
it is declared. The approach is adopted from
b5b55963f6.

This results in a change to the use list order, which is why we see
test changes on some module passes that are not stable under use list
reordering.

Differential Revision: https://reviews.llvm.org/D104950
2021-06-29 20:10:31 +02:00
Joseph Huber
01b46e36dd [OpenMP] Run the OpenMPOpt module pass at O1
Now that the OpenMPOpt module pass include important optimizations for removing
globalization from offloading regions it should be run at a lower optimization
level.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D105056
2021-06-28 18:47:41 -04:00
Nikita Popov
53eb678598 [Verifier] Support opaque pointers for global_ctors
Adjust the assertion to allow opaque pointers.
2021-06-28 21:40:54 +02:00
Nikita Popov
67a9e2940b [OpaquePtr] Enumerate GlobalAlias value type
The type is no longer implicitly enumerated through the pointer
type.
2021-06-25 21:21:10 +02:00
Nikita Popov
c5015ef621 [OpaquePtr] Allow alias to opaque pointer
By relaxing the LLParser pointer type assertion.
2021-06-25 11:16:36 +02:00
Nikita Popov
dbbb814b5c [OpaquePtr] Split force-opaque-pointers test (NFC)
Separate out the case that uses llvm-dis without
--force-opaque-pointers. This will generally produce a different
result from the other cases, because things like global symbol
pointers will be non-opaque in this case.
2021-06-25 11:16:35 +02:00
Nikita Popov
239cd8753c [OpaquePtr] Enumerate alloca type
This is no longer implicitly enumerated through the pointer type.
2021-06-25 10:48:57 +02:00
Nikita Popov
f01894d368 [OpaquePtr] Enumerate global variable type
This is no longer implicitly enumerated through the pointer type.
2021-06-25 10:46:28 +02:00
Arthur Eubanks
8d9d580ae9 Revert "[BuildLibCalls/SimplifyLibCalls] Fix attributes on created CallInst instructions."
This reverts commit 1eda5453f2dcc9a9a4b4578fe74163c529974503.

Causes https://crbug.com/1223647:
Incompatible argument and return types for 'returned' attribute
  tail call void @llvm.memset.p0i8.i64(i8* noalias noundef returned writeonly align 1 dereferenceable(255) %arraydecay, i8 0, i64 255, i1 false), !dbg !985
2021-06-24 19:24:34 -07:00
Arthur Eubanks
5cfe2f65b5 [OpaquePtr] Introduce option to force all pointers to be opaque pointers
We don't want to start updating tests to use opaque pointers until we're
close to the opaque pointer transition. However, before the transition
we want to run tests as if pointers are opaque pointers to see if there
are any crashes.

At some point when we have a flag to only create opaque pointers in the
bitcode and textual IR readers, and when we have fixed all places that
try to read a pointee type, this flag will be useless. However, until
then, this can help us find issues more easily.

Since the cl::opt is read into LLVMContext, we need to make sure
LLVMContext is created after cl::ParseCommandLineOptions().

Previously ValueEnumerator would visit the value types of global values
via the pointer type, but with opaque pointers we have to manually visit
the value type.

Reviewed By: nikic, dexonsmith

Differential Revision: https://reviews.llvm.org/D103503
2021-06-24 13:32:31 -07:00
Jonas Paulsson
e511168087 [BuildLibCalls/SimplifyLibCalls] Fix attributes on created CallInst instructions.
- When emitting libcalls, do not only pass the calling convention from the
  function prototype but also the attributes.

- Do not pass attributes from e.g. libc memcpy to llvm.memcpy.

Review: Reid Kleckner, Eli Friedman, Arthur Eubanks

Differential Revision: https://reviews.llvm.org/D103992
2021-06-24 14:47:24 -05:00
Bjorn Pettersson
a73e012b96 [NewPM] Print passes with params when using "opt -print-passes"
Make sure we also print passes with params when using "opt -print-passes".

Differential Revision: https://reviews.llvm.org/D104625
2021-06-22 09:01:38 +02:00
David Green
51d7c2c19b [DSE] Remove stores in the same loop iteration
DSE will currently only remove stores in the same block unless they can
be guaranteed to be loop invariant. This expands that to any stores that
are in the same Loop, at the same loop level. This should still account
for where AA/MSSA will not handle aliasing between loops, but allow the
dead stores to be removed where they overlap in the same loop iteration.
It requires adding loop info to DSE, but that looks fairly harmless.

The test case this helps is from code like this, which can come up in
certain matrix operations:
  for(i=..)
    dst[i] = 0;
    for(j=..)
      dst[i] += src[i*n+j];

After LICM, this becomes:
for(i=..)
  dst[i] = 0;
  sum = 0;
  for(j=..)
    sum += src[i*n+j];
  dst[i] = sum;

The first store is dead, and with this patch is now removed.

Differntial Revision: https://reviews.llvm.org/D100464
2021-06-20 17:03:30 +01:00
Joachim Meyer
473878f311 Use -cfg-func-name value as filter for -view-cfg, etc.
Currently the value is only used when calling `F->viewCFG()` which is missing out on its potential and usefulness.
So I added the check to the printer passes as well.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D102011
2021-06-16 23:54:51 +02:00
Roman Lebedev
10ca53ce65 [NewPM] Remove SpeculateAroundPHIs pass
Addition of this pass has been botched.
There is no particular reason why it had to be sold as an inseparable part
of new-pm transition. It was added when old-pm was still the default,
and very *very* few users were actually tracking new-pm,
so it's effects weren't measured.

Which means, some of the turnoil of the new-pm transition
are actually likely regressions due to this pass.

Likewise, there has been a number of post-commit feedback
(post new-pm switch), namely
* https://reviews.llvm.org/D37467#2787157 (regresses HW-loops)
* https://reviews.llvm.org/D37467#2787259 (should not be in middle-end, should run after LSR, not before)
* https://reviews.llvm.org/D95789 (an attempt to fix bad loop backedge metadata)
and in the half year past, the pass authors (google) still haven't found time to respond to any of that.

Hereby it is proposed to backout the pass from the pipeline,
until someone who cares about it can address the issues reported,
and properly start the process of adding a new pass into the pipeline,
with proper performance evaluation.

Furthermore, neither google nor facebook reports any perf changes
from this change, so i'm dropping the pass completely.
It can always be re-reverted should/if anyone want to pick it up again.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D104099
2021-06-15 20:35:55 +03:00
David Green
80ea5748b2 Revert "[DSE] Remove stores in the same loop iteration"
Apparently non-dead stores are being removed, as noted in D100464.

This reverts commit 222aeb4d51a46c5a81c9e4ccb16d1d19dd21ec95.
2021-06-08 21:23:08 +01:00
Arthur Eubanks
8967f0ab59 [test] Properly match parameter/argument ABI attributes
These were found with D103412.
2021-05-31 09:12:18 -07:00
Arthur Eubanks
7178161bf7 Remove "Rewrite Symbols" from codegen pipeline
It breaks up the function pass manager in the codegen pipeline.

With empty parameters, it looks at the -mllvm flag -rewrite-map-file.
This is likely not in use.

Add a check that we only have one function pass manager in the codegen
pipeline.

Some tests relied on the fact that we had a module pass somewhere in the
codegen pipeline.

addr-label.ll crashes on ARM due to this change. This is because a
ARMConstantPoolConstant containing a BasicBlock to represent a
blockaddress may hold an invalid pointer to a BasicBlock if the
blockaddress is invalidated by its BasicBlock getting removed. In that
case all referencing blockaddresses are RAUW a constant int. Making
ARMConstantPoolConstant::CVal a WeakVH fixes the crash, but I'm not sure
that's the right fix. As a workaround, create a barrier right before
ISel so that IR optimizations can't happen while a
ARMConstantPoolConstant has been created.

Reviewed By: rnk, MaskRay, compnerd

Differential Revision: https://reviews.llvm.org/D99707
2021-05-31 08:32:36 -07:00
David Green
3f23eb7a31 [DSE] Remove stores in the same loop iteration
DSE will currently only remove stores in the same block unless they can
be guaranteed to be loop invariant. This expands that to any stores that
are in the same Loop, at the same loop level. This should still account
for where AA/MSSA will not handle aliasing between loops, but allow the
dead stores to be removed where they overlap in the same loop iteration.
It requires adding loop info to DSE, but that looks fairly harmless.

The test case this helps is from code like this, which can come up in
certain matrix operations:
  for(i=..)
    dst[i] = 0;
    for(j=..)
      dst[i] += src[i*n+j];

After LICM, this becomes:
for(i=..)
  dst[i] = 0;
  sum = 0;
  for(j=..)
    sum += src[i*n+j];
  dst[i] = sum;

The first store is dead, and with this patch is now removed.

Differntial Revision: https://reviews.llvm.org/D100464
2021-05-31 10:22:37 +01:00
Florian Hahn
20c74f6c60 [Matrix] Include matrix pipeline for new PM in new-pm-defaults.ll.
-enable-matrix just adds a single pass, so it's easier to just check in
new-pm-default.ll rather than duplicating the full checks for -O3 with
the new pass manager.

Suggested post-commit by @aeubanks.
2021-05-27 10:57:39 +01:00
Arthur Eubanks
05ebdcd268 Making Instrumentation aware of LoopNest Pass
Intrumentation callbacks are not made aware of LoopNest passes. From the loop pass manager, we can pass the outermost loop of the LoopNest to instrumentation in case of LoopNest passes.

The current patch made the change in two places in StandardInstrumentation.cpp. I will submit a proper patch where the OuterMostLoop is passed from the LoopPassManager to the call backs. That way we will avoid making changes at multiple places in StandardInstrumentation.cpp.

A testcase also will be submitted.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D102463
2021-05-24 20:25:52 -07:00
serge-sans-paille
73bc91a5e6 Revert "[NFC] remove explicit default value for strboolattr attribute in tests"
This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247.

See https://lab.llvm.org/buildbot/#/builders/109/builds/15424 for instance
2021-05-24 19:43:40 +02:00
serge-sans-paille
1f63b26006 [NFC] remove explicit default value for strboolattr attribute in tests
Since d6de1e1a71406c75a4ea4d5a2fe84289f07ea3a1, no attributes is quivalent to
setting attribute to false.

This is a preliminary commit for https://reviews.llvm.org/D99080
2021-05-24 19:31:04 +02:00
Arthur Eubanks
1514e1d07b Revert "[NewPM] Only invalidate modified functions' analyses in CGSCC passes"
This reverts commit d14d84af2f5ebb8ae2188ce6884a29a586dc0a40.

Causes unacceptable memory regressions.
2021-05-21 16:38:03 -07:00
Arthur Eubanks
6347acc246 Revert "[NPM] Do not run function simplification pipeline unnecessarily"
This reverts commit 97ab068034161fb35e5c9a7b293bf1e569cf077b.

Depends on D100917, which is to be reverted.
2021-05-21 16:38:02 -07:00
Eli Friedman
627b91d7fb [NewPM] Mark BitcodeWriter as required.
The textual IR writer has an equivalent marking.  It looks like this got
missed in e6ea877.
2021-05-21 16:14:09 -07:00
Arthur Eubanks
99f72113f5 [NewPM] Add options to PrintPassInstrumentation
To bring D99599's implementation in line with the existing
PrintPassInstrumentation, and to fix a FIXME, add more customizability
to PrintPassInstrumentation.

Introduce three new options. The first takes over the existing
"-debug-pass-manager-verbose" cl::opt.

The second and third option are specific to -fdebug-pass-structure. They
allow indentation, and also don't print analysis queries.

To avoid more golden file tests than necessary, prune down the
-fdebug-pass-structure tests.

Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D102196
2021-05-18 20:59:35 -07:00
Florian Hahn
f52bf2cd81 [Matrix] Fix some newpm check lines, which fail on some bots. (2) 2021-05-16 14:11:18 +01:00
Florian Hahn
ed4cb46d3b [Matrix] Fix some newpm check lines, which fail on some bots. 2021-05-16 13:47:46 +01:00
Florian Hahn
c5a35017b8 [Matrix] Extend test to also check new PM pipeline. 2021-05-16 13:08:51 +01:00
Arthur Eubanks
6e23cf88e5 [test] Fix new-pm-lto-defaults.ll to work on all platforms
https://lab.llvm.org/buildbot/#/builders/119/builds/3775/steps/8/logs/FAIL__LLVM__new-pm-lto-defaults_ll

Followup to D102345.
2021-05-13 18:12:55 -07:00
Florian Hahn
234c1d0991 [Passes] Use regex to match GlobalsAA line in test.
On some platforms/compiler combinations, it appears the output is
slightly different. Update the test to use a regex, as is done at other
places in the new-pm-*default.ll tests to address buildbot failures.
2021-05-13 13:22:18 +01:00
Florian Hahn
d9eecce8c3 [Passes] Run GlobalsAA before LICM during LTO in new PM.
This patch adjusts the LTO pipeline in the new PM to run GlobalsAA
before LICM to match the legacy PM.

This fixes a regression where the new PM failed to vectorize loops that
require hoisting/sinking by LICM depending on GlobalsAA info.

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D102345
2021-05-13 13:11:18 +01:00
Florian Hahn
9aee17d8b4 [Passes] Use MemorySSA for LICM during LTO.
Split off from D102345 to commit this separately from other changes in
the patch. This aligns the behavior of the new PM with the legacy PM
for LTO, with respect to running LICM.

Together with the remaining changes in D102345, this fixes new PM
regressions where we fail to vectorize loops that are vectorized with
the legacy PM.
2021-05-13 12:16:41 +01:00
Qiu Chaofan
42b67ab7d1 [VectorCombine] Simplify to scalar store if only one element updated
This patch simplifies load-insertelt-store pattern into
getelementptr-store.

Reviewed By: fhahn

Differential Revision: https://reviews.llvm.org/D98240
2021-05-08 18:14:51 +08:00
Arthur Eubanks
b987f39d75 [NewPM] Hide pass manager debug logging behind -debug-pass-manager-verbose
Printing pass manager invocations is fairly verbose and not super
useful.

This allows us to remove DebugLogging from pass managers and PassBuilder
since all logging (aside from analysis managers) goes through
instrumentation now.

This has the downside of never being able to print the top level pass
manager via instrumentation, but that seems like a minor downside.

Reviewed By: ychen

Differential Revision: https://reviews.llvm.org/D101797
2021-05-07 21:51:47 -07:00