Summary:
When lowering global address, lower the base as a TargetGlobal first then
create an SDNode for the offset separately and chain it to the address calculation
This optimization will create a DAG where the base address of a global access will
be reused between different access. The offset can later be folded into the immediate
part of the memory access instruction.
With this optimization we generate:
lui a0, %hi(s)
addi a0, a0, %lo(s) ; shared base address.
addi a1, zero, 20 ; 2 instructions per access.
sw a1, 44(a0)
addi a1, zero, 10
sw a1, 8(a0)
addi a1, zero, 30
sw a1, 80(a0)
Instead of:
lui a0, %hi(s+44) ; 3 instructions per access.
addi a1, zero, 20
sw a1, %lo(s+44)(a0)
lui a0, %hi(s+8)
addi a1, zero, 10
sw a1, %lo(s+8)(a0)
lui a0, %hi(s+80)
addi a1, zero, 30
sw a1, %lo(s+80)(a0)
Which will save one instruction per access.
Reviewers: asb, apazos
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, apazos, asb, llvm-commits
Differential Revision: https://reviews.llvm.org/D46989
llvm-svn: 332641
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in https://reviews.llvm.org/D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332640
MethodVFTableLocations in MigrosoftVTableContext contains canonicalized
decl. But, it's sometimes asked to lookup for non-canonicalized decl,
and that causes assertion failure, and compilation failure.
Fixes PR37481.
Patch by Taiju Tsuiki!
Differential Revision: https://reviews.llvm.org/D46929
llvm-svn: 332639
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in https://reviews.llvm.org/D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332638
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in https://reviews.llvm.org/D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
Follow-up to:
https://reviews.llvm.org/rL332538
...because that change wasn't enough.
llvm-svn: 332637
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
Follow-up to:
https://reviews.llvm.org/rL332534
...because that change wasn't enough.
llvm-svn: 332636
This is to work around a bug in some versions of gnu ld, where
--export-dynamic implies -shared even if -static is explicitly given.
Myriad supports static linking only, so --export-dynamic is never
needed.
Differential Revision: https://reviews.llvm.org/D46452
llvm-svn: 332635
Summary:
This patch implements MC support for tail psuedo instruction.
A follow-up patch implements the codegen support as well as handling of the indirect tail pseudo instruction.
Reviewers: asb, apazos
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, llvm-commits
Differential Revision: https://reviews.llvm.org/D46221
llvm-svn: 332634
Summary:
This patch adds a new internal variable
LLVM_RUNTIME_DISTRIBUTION_COMPONENTS which specifies distribution
components that are part of runtime projects, and thus should be exposed
from runtime configuraitons up into the top-level CMake configurations.
This is required for allowing runtime components to be included in
LLVM_DISTRIBUTION_COMPONENTS because we verify that the build and
install targets exist for every component specified for the
distribution.
Without this patch runtimes and builtins can only be included in
distributions in whole, not by component.
Reviewers: phosek
Reviewed By: phosek
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46705
llvm-svn: 332631
Summary: These three tests are failing on Windows and looking into the failures, they could be mapped to pr21765 and pr24489
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47018
llvm-svn: 332629
This behavior has been the default for a long time, so the default value is On, however this can make it difficult to debug sanitizer failures, so we should have an option to turn it off.
llvm-svn: 332628
Summary:
The current StructurizeCFG pass only works for CFG with one exit. AMDGPUUnifyDivergentExitNodes combines multiple "return" blocks and/or "unreachable" blocks
to one exit block for the Structurizer to work. However, infinite loop is another kind of special "exit", and if we don't handle it, the case of multiple exits will prevent the structurizer from working.
In this work, for each infinite loop, we add a dummy edge to the "return" block, and thus the AMDGPUUnifyDivergentExitNodes pass will work with infinite loops.
This will make CFG with infinite loops be structurized.
Reviewer:
nhaehnle
Differential Revision:
https://reviews.llvm.org/D46340
llvm-svn: 332625
According to alive this is valid. I'm hoping to use this to make an assumption that the sign bit is zero after this sequence. The only way it wouldn't be is if the input was INT__MIN, but by preserving the flags we can make doing this to INT_MIN UB.
The nuw flags is weird because it creates such a contradiction that the original number would have to be positive meaning we could remove the select entirely, but we don't get that far.
Differential Revision: https://reviews.llvm.org/D46988
llvm-svn: 332623
Summary:
Previously this triggered a -Wundefined-internal warning. But it's not
an undefined variable -- any variable of this form is a pointer to the
base of GPU core's shared memory.
Reviewers: tra
Subscribers: sanjoy, rsmith
Differential Revision: https://reviews.llvm.org/D46782
llvm-svn: 332621
This was broken by r332590 but is likely caused by a bug in clang-move.
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/12007
I don't have a windows machine to effectively debug the issue, so I'll investigate
further but for now disable the failing test on windows to unbreak build bots.
llvm-svn: 332620
After switching to LLVM normalization, if we init FileSpec with "." we would end up with m_directory being NULL and m_filename being "".
This patch fixes this by allowing the path to be normalized and if it normalized to nothing, set it to m_filename.
Differential Revision: https://reviews.llvm.org/D46783
llvm-svn: 332618
The isReMaterlizable flag is somewhat confusing, unlike most other instruction
flags it is currently interpreted as a hint (mightBeRematerializable would be
a better name). While LUI is always rematerialisable, for an instruction like
ADDI it depends on its operands. TargetInstrInfo::isTriviallyReMaterializable
will call TargetInstrInfo::isReallyTriviallyReMaterializable, which in turn
calls TargetInstrInfo::isReallyTriviallyReMaterializableGeneric. We rely on
the logic in the latter to pick out instances of ADDI that really are
rematerializable.
The isReMaterializable flag does make a difference on a variety of test
programs. The recently committed remat.ll test case demonstrates how stack
usage is reduce and a unnecessary lw/sw can be removed. Stack usage in the
Proc0 function in dhrystone reduces from 192 bytes to 112 bytes.
For the sake of completeness, this patch also implements
RISCVRegisterInfo::isConstantPhysReg. Although this is called from a number of
places, it doesn't seem to result in different codegen for any programs I've
thrown at it. However, it is called in the rematerialisation codepath and it
seems sensible to implement something correct here.
Differential Revision: https://reviews.llvm.org/D46182
llvm-svn: 332617
Clang used to pass the base lvalue of a non-type template parameter
to the template instantiation phase when the base part is __uuidof
and it's running in C++17 mode.
However, that drops its LValuePath, and unintentionally transforms
&__uuidof(...) to __uuidof(...).
This CL fixes that by passing whole expr. Fixes PR24986.
https://reviews.llvm.org/D46820?id=146557
Patch from Taiju Tsuiki <tzik@chromium.org>!
llvm-svn: 332614
Previously we would always write a hash of the binary into the
PE file, for reproducible builds. This breaks AppCompat, which
is a feature of Windows that relies on the timestamp in the PE
header being set to a real value (or at the very least, a value
that satisfies certain properties).
To address this, we put the old behavior of writing the hash
behind the /Brepro flag, which mimics MSVC linker behavior. We
also match MSVC default behavior, which is to write an actual
timestamp to the PE header. Finally, we add the /TIMESTAMP
option (an lld extension) so that the user can specify the exact
value to be used in case he/she manually constructs a value which
is both reproducible and satisfies AppCompat.
Differential Revision: https://reviews.llvm.org/D46966
llvm-svn: 332613
entries to reach the target. Since these calls don't require type checks,
we can short-circuit them to their real targets.
Differential Revision: https://reviews.llvm.org/D46326
llvm-svn: 332610
Summary: The alpha checkers can already be enabled using the clang driver, this allows them to be enabled using the clang-tidy as well. This can make it easier to test the alpha checkers with projects which already support the compile_commands.json. It will also allow more people to give feedback and patches about the alpha checkers since they can run it as part of clang tidy checks.
Reviewers: aaron.ballman, hokein, ilya-biryukov, alexfh, lebedev.ri, xbolva00
Reviewed By: aaron.ballman, alexfh, lebedev.ri, xbolva00
Subscribers: xbolva00, NoQ, dcoughlin, lebedev.ri, xazax.hun, cfe-commits
Patch by Paul Fultz II!
Differential Revision: https://reviews.llvm.org/D46159
llvm-svn: 332609
Data directives such as .word, .half, .hword are currently parsed using
HexagonAsmParser::ParseDirectiveValue which effectively duplicates logic from
AsmParser::parseDirectiveValue. This patch deletes that duplicated logic in
favour of using addAliasForDirective.
Differential Revision: https://reviews.llvm.org/D46999
llvm-svn: 332607
The existing test for the AArch64 inline assembly constraint S uses the
A and L modifiers. These modifiers were implemented in the original
AArch64 backend but were not carried forward to the merged backend. The
A is associated with ADRP and does nothing, the L is associated with
:lo12: . Given that A and L are not supported by GCC and not supported
by the new implementation of constraint S in LLVM (see D46745) I've
altered the test to put :lo12: directly in the string so that A and L
are not needed.
Differential Revision: https://reviews.llvm.org/D46932
llvm-svn: 332606
Summary:
Warn on instructions that should have the same performance
characteristics according to the sched model but actually
differ in their benchmarks.
Next step: Make the display nicer to browse, I was thinking maybe html.
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D46945
llvm-svn: 332601
E. g. use "10.11" instead of "10_11".
We are maintaining backward compatibility by parsing underscore-delimited version tuples but no longer keep track of the separator and using dot format for output.
Differential Revision: https://reviews.llvm.org/D46747
rdar://problem/39845032
llvm-svn: 332598
Summary:
The DataExtractors are cheap to copy so there is no reason to store them
by reference. Also, in my upcoming indexing refactor I am planning to
remove the apple tables data extractor members from the SymbolFileDWARF
class, so there will not be a DataExtractor with a suitable lifetime to
refer to.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46888
llvm-svn: 332596
lifetime.start/end expects pointer argument in alloca address space.
However in C++ a temporary variable is in default address space.
This patch changes API CreateMemTemp and CreateTempAlloca to
get the original alloca instruction and pass it lifetime.start/end.
It only affects targets with non-zero alloca address space.
Differential Revision: https://reviews.llvm.org/D45900
llvm-svn: 332593
Restructuring the code to measure latency and uops.
The end goal is to have this program spawn another process to deal with SIGILL and other malformed programs. It is not yet the case in this redesign, it is still the main program that runs the code (and may crash).
It now uses BitVector instead of Graph for performance reasons.
https://reviews.llvm.org/D46821
(with fixed ARM tests)
Authored by Guillaume Chatelet
llvm-svn: 332592
