Copy the logic from the existing handling in the DAG matcher emittter.
This will enable some AMDGPU pattern cleanups without breaking
GlobalISel tests, and eventually handle importing more patterns.
The test is a bit annoying since the sections seem to randomly sort
themselves if anything else is added in the future.
Looking at a sometimes-passing test case on a platform
where random values were being returned - sometimes
the expected digit ('1' or '2') would be included in the
random returned value. Add a prefix to reduce the likelihood of
this a bit.
Summary:
Qsort interceptor suppresses all checks by unpoisoning the data in the
wrapper of a comparator function, and then unpoisoning the output array
as well.
This change adds an explicit run of the comparator on all elements of
the input array to catch any sanitizer bugs.
Reviewers: vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D71780
The install-${name}-stripped targets don't strip when ${name} is being
symlinked, e.g. llvm-ar or llvm-objcopy. The problem is that
llvm_install_symlink passes install-${dest} as a dependency of
install-${name}, e.g. install-llvm-ar becomes a dependency of both
install-llvm-ranlib and install-llvm-ranlib-stripped. What this means is
that when installing a distribution that contains both llvm-ar and
llvm-ranlib is that first the stripped version of llvm-ar is installed
(by the install-llvm-ar-stripped target) and then it's overwritten by an
unstripped version of llvm-ar bnecause install-llvm-ranlib-stripped has
install-llvm-ranlib as a dependency as mentioned earlier. To avoid this
issue, rather than passing the install-${dest} as dependency, we
introduce a new argument to add_llvm_install_targets for symlink target
which expands it into an appropriate dependency, i.e. install-${dest}
for install-${name} target and install-${dest}-stripped for
install-${name}-stripped.
Differential Revision: https://reviews.llvm.org/D71951
Summary:
It's not necessary to use an 'l'(ell) modifier when referencing a label.
Treat block addresses and MBB references as if the modifier is used
anyway. This prevents us from generating references to ficticious
labels.
Reviewers: jyknight, nickdesaulniers, hfinkel
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71849
Summary:
When FileCheck was made a library, types in the public API were renamed
to add a FileCheck prefix, such as Pattern to FileCheckPattern. Many
types were moved into a private interface and thus don't need this
prefix anymore. This commit removes those unneeded prefixes.
Reviewers: jhenderson, jdenny, probinson, grimar, arichardson, rnk
Reviewed By: jhenderson
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72186
We use o suffix to indicate record form instuctions,
(as it is similar to dot '.' in mne?)
This was fine before, as we did not support XO-form.
However, with https://reviews.llvm.org/D66902,
we now have XO-form support.
It becomes confusing now to still use 'o' for record form,
and it is weird to have something like 'Oo' .
This patch rename all 'o' instructions to use '_rec' instead.
Also rename `isDot` to `isRecordForm`.
Reviewed By: #powerpc, hfinkel, nemanjai, steven.zhang, lkail
Differential Revision: https://reviews.llvm.org/D70758
This would complain about invalid legalizer rules otherwise.
Mark some operations as unsupported for AMDGPU. This currently seems
to produce the same legalize error as when no rules are defined, but
eventually this should produce a proper user facing error.
The existing test only covered one case for r600. The use of
mul_legacy also looks suspicious to me, but leave it for now. The
patterns are also not making use of source modifiers.
A random set of attributes are implemented by llc/opt forcing the
string attributes on the IR functions before processing anything. This
would not happen for MIR functions, which have not yet been created at
this point.
Use a callback in the MIR parser, purely to avoid dealing with the
ugliness that the command line flags are in a .inc file, and would
require allowing access to these flags from multiple places (either
from the MIR parser directly, or a new utility pass to implement these
flags). It would probably be better to cleanup the flag handling into
a separate library.
This is in preparation for treating more command line flags with a
corresponding function attribute in a more uniform way. The fast math
flags in particular have a messy system where the command line flag
sets the behavior from a function attribute if present, and otherwise
the command line flag. This means if any other pass tries to inspect
the function attributes directly, it will be inconsistent with the
intended behavior. This is also inconsistent with the current behavior
of -mcpu and -mattr, which overwrites any pre-existing function
attributes. I would like to move this to consistenly have the command
line flags not overwrite any pre-existing attributes, and to always
ensure the command line flags are consistent with the function
attributes.
This patch adds widening which really just scalarizes because we don't have a strategy for the extra elements we would need to pad with.
Differential Revision: https://reviews.llvm.org/D72193
Summary:
This never really occurs in the current codegen, so only a MIR test is
possible.
Reviewers: ostannard, pcc
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72123
In https://reviews.llvm.org/D67148, we use isFloatTy to test floating
point type, otherwise we return GPRRC.
So 'double' will be classified as GPRRC, which is not accurate.
This patch covers other floating point types.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D71946
A toplevel target, `check-libc` has also been added.
Reviewers: abrachet, phosek
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D72177
My earlier change for Python auto-detection caused PYTHON_HOME to be set
unconditionally, while before the change this only happened for Windows.
This caused the PythonDataObjectsTest to fail with an import error.
Summary:
lib/python2.7/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so,
which depends on lib/libLLVM*.so (-DBUILD_SHARED_LIBS=ON) or lib/libLLVM-10git.so
(-DLLVM_LINK_LLVM_DYLIB=ON). Add an additional rpath `$ORIGIN/../../../../lib` so
that _lldb.so can be loaded from Python.
This fixes an import error from lib/python2.7/dist-packages/lldb/__init__.py
from . import _lldb
ImportError: libLLVMAArch64CodeGen.so.10git: cannot open shared object file: No such file or directory
The following configurations will work:
* -DBUILD_SHARED_LIBS=ON
* -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON
* -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON -DCLANG_LINK_CLANG_DYLIB=ON
(-DCLANG_LINK_CLANG_DYLIB=ON depends on -DLLVM_LINK_LLVM_DYLIB=ON)
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D71800
While looking at cycle time graphs of some of my bots, I noticed
that 327894859c made check-llvm noticeably slower on macOS and
Windows.
As it turns out, the 5 substitutions added in that change were
enough to cause lit to thrash the build-in cache in re.compile()
(re.sub() is implemented as re.compile().sub()), and apparently
applySubstitutions() is on the cricital path and slow when all
regexes need to compile all the time.
(See `_MAXCACHE = 512` in cpython/Lib/re.py)
Supporting full regexes for lit substitutions seems a bit like
overkill, but for now add a simple unbounded cache to recover
the lost performance.
No intended behavior change.
Summary:
This check searches for signed char -> integer conversions which might
indicate programming error, because of the misinterpretation of char
values. A signed char might store the non-ASCII characters as negative
values. The human programmer probably expects that after an integer
conversion the converted value matches with the character code
(a value from [0..255]), however, the actual value is in
[-128..127] interval.
See also:
STR34-C. Cast characters to unsigned char before converting to larger integer sizes
<https://wiki.sei.cmu.edu/confluence/display/c/STR34-C.+Cast+characters+to+unsigned+char+before+converting+to+larger+integer+sizes>
By now this check is limited to assignment / variable declarations.
If we would catch all signed char -> integer conversion, then it would
produce a lot of findings and also false positives. So I added only
this use case now, but this check can be extended with additional
use cases later.
The CERT documentation mentions another use case when the char is
used for array subscript. Next to that a third use case can be
the signed char - unsigned char comparison, which also a use case
where things happen unexpectedly because of conversion to integer.
Reviewers: alexfh, hokein, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: sylvestre.ledru, whisperity, Eugene.Zelenko, mgorny, xazax.hun, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D71174
Python was the last remaining "optional" dependency for LLDB. This moves
the code to find Python into FindPythonInterpAndLibs using the same
principles as FindCursesAndPanel.
Differential revision: https://reviews.llvm.org/D72107
SUMMARY:
We currently emit a reference for function address constants as labels;
for example:
foo_ptr:
.long foo
however, there may be no such label in the case where the function is
undefined. Although the label exists when the function is defined, we
will (to be consistent) also use a csect reference in that case.
Address one comment
https://reviews.llvm.org/D71144#inline-653255
Reviewers: daltenty,hubert.reinterpretcast,jasonliu,Xiangling_L
Subscribers: cebowleratibm, wuzish, nemanjai
Differential Revision: https://reviews.llvm.org/D71144
The segmented stack lowering code appears to be using ARM opcodes under
Thumb2. The MRC opcode will be the same for Thumb and ARM, but t2LDR
seems wrong. Either way, using the correct thumb vs arm opcodes is more
correct.
Differential Revision: https://reviews.llvm.org/D72074
We were previously unconditionally using the ARM::TRAP opcode, even
under Thumb. My understanding is that these are essentially the same
thing (they both result in a trap under Thumb), but the ARM::TRAP opcode
is marked as requiring IsARM, so it is more correct to use ARM::tTRAP.
Differential Revision: https://reviews.llvm.org/D72075
SUMMARY:
We currently emit a reference for function address constants as labels;
for example:
foo_ptr:
.long foo
however, there may be no such label in the case where the function is
undefined. Although the label exists when the function is defined, we
will (to be consistent) also use a csect reference in that case.
Reviewers: daltenty,hubert.reinterpretcast,jasonliu,Xiangling_L
Subscribers: cebowleratibm, wuzish, nemanjai
Differential Revision: https://reviews.llvm.org/D71144
This makes the range loop warnings part of -Wall.
Fixes PR32823: Warn about accidental coping of data in range based for
Differential Revision: https://reviews.llvm.org/D68912
Recomitted after fixing the warnings it created.
Matt Arsenault