| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 297959
|
| |
|
|
|
|
|
|
|
|
| |
We can mark functions to always inline early in the opt. Since we do not have
call support this early inlining creates opportunities for inter-procedural
optimizations which would not occur otherwise.
Differential Revision: https://reviews.llvm.org/D31016
llvm-svn: 297958
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30116
llvm-svn: 297955
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The call to canEvaluateZExtd in InstCombiner::visitZExt may
return with BitsToClear == SrcTy->getScalarSizeInBits(), but
there is an assert that BitsToClear should be smaller than
SrcTy->getScalarSizeInBits().
I have a test case that triggers the assert, but it only happens
for my downstream target. I've not been able to trigger it for
any upstream target.
The assert triggered for a piece of code such as this
%shr1 = lshr i16 undef, 15
...
%shr2 = lshr i16 %shr1, 1
%conv = zext i16 %shr2 to i32
Normally the lshr instructions are constant folded before we
visit the zext (that is why it is so hard to reproduce).
The original pattern, before instcombine, is of course a lot more
complicated in my test case. The shift count in the second lshr
is for example determined by the outcome of a PHI instruction.
It seems like other rewrites by instcombine leads up to
the pattern above. And then the zext is pulled from the
worklist, and visited (hitting the assert), before we detect
that the lshr instrucions can be constant folded.
Anyway, since the canEvaluateZExtd may return with BitsToClear
equal to SrcTy->getScalarSizeInBits(), and since the rewrite
that converts the expression type to avoid a zero extend works
also for the case where SrcBitsKept ends up being zero, then
it should be OK to liberate the assert to
assert(BitsToClear <= SrcTy->getScalarSizeInBits() &&
"Unreasonable BitsToClear");
Reviewers: hfinkel
Reviewed By: hfinkel
Subscribers: hfinkel, llvm-commits
Differential Revision: https://reviews.llvm.org/D30993
llvm-svn: 297952
|
| |
|
|
|
|
| |
This commit reverts r297897 and r297909.
llvm-svn: 297951
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implement sys::fs::set/getPermissions to work with them
This change adds support for functions to set and get file permissions, in a similar manner to the C++17 permissions() function in <filesystem>. The setter uses chmod on Unix systems and SetFileAttributes on Windows, setting the permissions as passed in. The getter simply uses the existing status() function.
Prior to this change, status() would always return an unknown value for the permissions on a Windows file, making it impossible to test the new function on Windows. I have therefore added support for this as well. On Linux, prior to this change, the permissions included the file type, which should actually be accessed via a different member of the file_status class.
Note that on Windows, only the *_write permission bits have any affect - if any are set, the file is writable, and if not, the file is read-only. This is in common with what MSDN describes for their behaviour of std::filesystem::permissions(), and also what boost::filesystem does.
The motivation behind this change is so that we can easily test behaviour on read-only files in LLVM unit tests, but I am sure that others may find it useful in some situations.
Reviewers: zturner, amccarth, aaron.ballman
Differential Revision: https://reviews.llvm.org/D30736
llvm-svn: 297945
|
| |
|
|
|
|
|
| |
the work queue and crash when trying to visit them after deleting the
function containing those calls.
llvm-svn: 297940
|
| |
|
|
| |
llvm-svn: 297932
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't scalarize VSELECT->SETCC when operands/results needs to be widened,
or when the type of the SETCC operands are different from those of the VSELECT.
(VSELECT SETCC) and (VSELECT (AND/OR/XOR (SETCC,SETCC))) are handled.
The previous splitting of VSELECT->SETCC in DAGCombiner::visitVSELECT() is
no longer needed and has been removed.
Updated tests:
test/CodeGen/ARM/vuzp.ll
test/CodeGen/NVPTX/f16x2-instructions.ll
test/CodeGen/X86/2011-10-19-widen_vselect.ll
test/CodeGen/X86/2011-10-21-widen-cmp.ll
test/CodeGen/X86/psubus.ll
test/CodeGen/X86/vselect-pcmp.ll
Review: Eli Friedman, Simon Pilgrim
https://reviews.llvm.org/D29489
llvm-svn: 297930
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In commit r289548 ([ADCE] Add code to remove dead branches) a redundant loop
nest was accidentally introduced, which implements exactly the same
functionality as has already been available right after. This redundancy has
been found when inspecting the ADCE code in the context of our recent
discussions on post-dominator modeling. This redundant code was also eliminated
by r296535 (which sparked the discussion), but only as part of a larger semantic
change of the post-dominance modeling. As this redundency in [ADCE] is really
just an oversight completely independent of the post-dominance changes under
discussion, we remove this redundancy independently.
Reviewers: dberlin, david2050
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31023
llvm-svn: 297929
|
| |
|
|
| |
llvm-svn: 297928
|
| |
|
|
|
|
|
|
|
| |
The idea is that the policy string fully specifies the policy and is portable
between clients.
Differential Revision: https://reviews.llvm.org/D31020
llvm-svn: 297927
|
| |
|
|
|
|
|
|
|
| |
This produces a 1% speedup on an important internal Google benchmark
(protocol buffers), with no other regressions in google or in the llvm
test-suite. Only 5 targets in the entire llvm test-suite are affected,
and on those 5 targets the size increase is 0.027%
llvm-svn: 297925
|
| |
|
|
|
|
| |
they're empty at the end of a section
llvm-svn: 297922
|
| |
|
|
|
|
| |
function calls
llvm-svn: 297921
|
| |
|
|
| |
llvm-svn: 297920
|
| |
|
|
|
|
| |
(https://github.com/google/oss-fuzz/issues/460)
llvm-svn: 297919
|
| |
|
|
| |
llvm-svn: 297916
|
| |
|
|
| |
llvm-svn: 297915
|
| |
|
|
| |
llvm-svn: 297913
|
| |
|
|
|
|
|
|
| |
Fails LLVMFuzzer.LLVMFuzzer.value-profile-strncmp.test.
This reverts commit r297891.
llvm-svn: 297912
|
| |
|
|
|
|
|
|
|
|
| |
SelectInstVisitor.""
Previously reverted wrong revision.
This reverts commit r297910.
llvm-svn: 297911
|
| |
|
|
|
|
|
|
| |
Fails LLVMFuzzer.LLVMFuzzer.value-profile-strncmp.test
This reverts commit r297892.
llvm-svn: 297910
|
| |
|
|
| |
llvm-svn: 297909
|
| |
|
|
|
|
|
|
|
| |
Change the function that implements the pruning into a free function that
takes the policy as a struct argument.
Differential Revision: https://reviews.llvm.org/D31009
llvm-svn: 297907
|
| |
|
|
|
|
| |
comment that indicated we were using it when we really use a depth-first search. NFC
llvm-svn: 297904
|
| |
|
|
| |
llvm-svn: 297903
|
| |
|
|
| |
llvm-svn: 297901
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we did not have support for writing detailed
module information for each module, as well as the symbol
records. This patch adds support for this, and in doing
so enables the ability to construct minimal PDBs from
just a few lines of YAML. A test is added to illustrate
this functionality.
llvm-svn: 297900
|
| |
|
|
| |
llvm-svn: 297898
|
| |
|
|
|
|
|
|
|
| |
This patch adds the value profile support to profile the size parameter of
memory intrinsic calls: memcpy, memcmp, and memmov.
Differential Revision: http://reviews.llvm.org/D28965
llvm-svn: 297897
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
NSIs can be double-counted by different operations in
SelectInstVisitor. Sink the the update to VM_counting mode only.
Also reset the value for each counting operation.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: xur, llvm-commits
Differential Revision: https://reviews.llvm.org/D30999
llvm-svn: 297892
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30683
llvm-svn: 297891
|
| |
|
|
| |
llvm-svn: 297887
|
| |
|
|
| |
llvm-svn: 297886
|
| |
|
|
|
|
|
|
|
|
|
| |
Together, these allow lldb-pdbdump to list all the modules from a PDB using a
native reader (rather than DIA).
Note that I'll probably be specializing NativeRawSymbol in a subsequent patch.
Differential Revision: https://reviews.llvm.org/D30956
llvm-svn: 297883
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes pr32278
Reviewers: igorb, craig.topper, RKSimon, spatel, hfinkel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30978
llvm-svn: 297878
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change updates to the format of the 'names' sectionin the
generated wasm binary to match the latest changesto the design
and 'wabt'.
Differential Revision: https://reviews.llvm.org/D30950
Patch by Sam Clegg
llvm-svn: 297877
|
| |
|
|
|
|
| |
Prep work for PR31810
llvm-svn: 297876
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we create a G_CONSTANT for every "synthetic" integer
constant operand (for instance, for the G_GEP offset).
Instead, share the G_CONSTANTs we might have created by going through
the ValueToVReg machinery.
When we're emitting synthetic constants, we do need to get Constants from
the context. One could argue that we shouldn't modify the context at
all (for instance, this means that we're going to use a tad more memory
if the constant wasn't used elsewhere), but constants are mostly
harmless. We currently do this for extractvalue and all.
For constant fcmp, this does mean we'll emit an extra COPY, which is not
necessarily more optimal than an extra materialized constant.
But that preserves the current intended design of uniqued G_CONSTANTs,
and the rematerialization problem exists elsewhere and should be
resolved with a single coherent solution.
llvm-svn: 297875
|
| |
|
|
|
|
|
| |
We're now able to select ADDWri thanks to the new complex pattern
support. Extend that to ADDXri.
llvm-svn: 297874
|
| |
|
|
|
|
|
|
|
| |
computeKnownBits didn't handle fp_to_fp16 to report
the high bits as 0. ARM maps the generic node to an instruction
that does not modify the high bits of the register, so introduce
a target node where the high bits are known 0.
llvm-svn: 297873
|
| |
|
|
|
|
|
|
|
|
|
| |
If we got unlucky with register allocation and actual constpool placement, we
could end up producing a tTBB_JT with an index that's already been clobbered.
Technically, we might be able to fix this situation up with a MOV, but I think
the constant islands pass is complex enough without having to deal with more
weird edge-cases.
llvm-svn: 297871
|
| |
|
|
|
|
|
|
|
| |
This patch refactors the code for value profile annotation to facilitate
of adding other kind of value profiles.
Differential Revision: http://reviews.llvm.org/D30989
llvm-svn: 297870
|
| |
|
|
|
|
|
|
|
| |
Now that we preserve the IR layout, we would end up with all the newly
synthesized switch comparison blocks at the end of the function.
Instead, use a hopefully more reasonable layout, with the comparison
blocks immediately following the switch comparison blocks.
llvm-svn: 297869
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It makes the output function layout more predictable; the layout has
an effect on performance, we don't want it to be at the mercy of the
translator's visitation order and such.
The predictable output is also easier to digest.
getOrCreateBB isn't appropriately named anymore, as it never needs to
create anything. Rename it and extract the MBB creation logic out of it.
A couple tests were sensitive to the order. Update them.
llvm-svn: 297868
|
| |
|
|
|
|
| |
Newline fixes, early return, range loops.
llvm-svn: 297865
|
| |
|
|
|
|
|
|
|
| |
Previously, if you attempted to write a key/value pair and the
value was equal to the key's default value, we would not output
the value. Sometimes it is useful to be able to see this value
in the output anyway.
llvm-svn: 297864
|
| |
|
|
|
|
|
|
|
|
| |
This patch replaces ORs with getHighBits/getLowBits etc. with setLowBits/setHighBits/setBitsFrom.
In a few of the places we weren't ORing, but the KnownZero/KnownOne vectors were already initialized to zero. We exploit this in most places already there were just some that were inconsistent.
Differential Revision: https://reviews.llvm.org/D30965
llvm-svn: 297860
|
| |
|
|
| |
llvm-svn: 297855
|