| Age | Commit message (Collapse) | Author |
|---|
|
------------------------------------------------------------------------
r345839 | erichkeane | 2018-11-01 08:11:43 -0700 (Thu, 01 Nov 2018) | 6 lines
Multiversioning- Ensure all MV functions are emitted.
Multiverson function versions are always used (by the resolver), so ensure that
they are always emitted.
Change-Id: I5d2e0841fddf0d18918b3fb92ae76814add7ee96
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r345838 | erichkeane | 2018-11-01 08:11:41 -0700 (Thu, 01 Nov 2018) | 8 lines
CPU-Dispatch- Fix type of a member function, prevent deferrals
The member type creation for a cpu-dispatch function was not correctly
including the 'this' parameter, so ensure that the type is properly
determined. Also, disable defer in the cases of emitting the functoins,
as it can end up resulting in the wrong version being emitted.
Change-Id: I0b8fc5e0b0d1ae1a9d98fd54f35f27f6e5d5d083
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r345826 | erichkeane | 2018-11-01 05:50:37 -0700 (Thu, 01 Nov 2018) | 15 lines
CPU-Dispatch-- Fix conflict between 'generic' and 'pentium'
When a dispatch function was being emitted that had both a generic and a
pentium configuration listed, we would assert. This is because neither
configuration has any 'features' associated with it so they were both
considered the 'default' version. 'pentium' lacks any features because
we implement it in terms of __builtin_cpu_supports (instead of Intel
proprietary checks), which is unable to decern between the two.
The fix for this is to omit the 'generic' version from the dispatcher if
both are present. This permits existing code to compile, and still will
choose the 'best' version available (since 'pentium' is technically
better than 'generic').
Change-Id: I4b69f3e0344e74cbdbb04497845d5895dd05fda0
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r342152 | erichkeane | 2018-09-13 09:58:24 -0700 (Thu, 13 Sep 2018) | 6 lines
[NFC]Refactor MultiVersion Resolver Emission to combine types
Previously, both types (plus the future target-clones) of
multiversioning had a separate ResolverOption structure and emission
function. This patch combines the two, at the expense of a slightly
more expensive sorting function.
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r348444 | matze | 2018-12-05 17:40:23 -0800 (Wed, 05 Dec 2018) | 15 lines
AArch64: Fix invalid CCMP emission
The code emitting AND-subtrees used to check whether any of the operands
was an OR in order to figure out if the result needs to be negated.
However the OR could be hidden in further subtrees and not immediately
visible.
Change the code so that canEmitConjunction() determines whether the
result of the generated subtree needs to be negated. Cleanup emission
logic to use this. I also changed the code a bit to make all negation
decisions early before we actually emit the subtrees.
This fixes http://llvm.org/PR39550
Differential Revision: https://reviews.llvm.org/D54137
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r346203 | matze | 2018-11-05 19:15:22 -0800 (Mon, 05 Nov 2018) | 7 lines
AArch64: Cleanup CCMP code; NFC
Cleanup CCMP pattern matching code in preparation for review/bugfix:
- Rename `isConjunctionDisjunctionTree()` to `canEmitConjunction()`
(it won't accept arbitrary disjunctions and is really about whether we
can transform the subtree into a conjunction that we can emit).
- Rename `emitConjunctionDisjunctionTree()` to `emitConjunction()`
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r340125 | lhames | 2018-08-18 11:38:37 -0700 (Sat, 18 Aug 2018) | 6 lines
[RuntimeDyld] Fix a bug in RuntimeDyld::loadObjectImpl that was over-allocating
space for common symbols.
Patch by Dmitry Sidorov. Thanks Dmitry!
Differential revision: https://reviews.llvm.org/D50240
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r340386 | inouehrs | 2018-08-21 22:43:27 -0700 (Tue, 21 Aug 2018) | 10 lines
[AST] correct the behavior of -fvisibility-inlines-hidden option (don't make static local variables hidden)
The command line option -fvisibility-inlines-hidden makes inlined method hidden, but it is expected not to affect the visibility of static local variables in the function.
However, Clang makes the static local variables in the function also hidden as reported in PR37595. This problem causes LLVM bootstarp failure on Fedora 28 if configured with -DBUILD_SHARED_LIBS=ON.
This patch makes the behavior of -fvisibility-inlines-hidden option to be consistent with that of gcc; the option does not change the visibility of the static local variables if the containing function does not associated with explicit visibility attribute and becomes hidden due to this option.
Differential Revision: https://reviews.llvm.org/D50968
------------------------------------------------------------------------
------------------------------------------------------------------------
r344190 | rnk | 2018-10-10 14:59:56 -0700 (Wed, 10 Oct 2018) | 19 lines
[AST] Use -fvisibility value when ignoring -fv-i-h* inline static locals
Summary:
In r340386 we added code to give static locals in inline functions
default visibility. Instead, we should use the "default" visibility
passed on the command line, which could be hidden or protected, as GCC
does.
Some code bases use both -fvisibility=hidden and
-fvisibility-inlines-hidden to hide inline functions of classes that are
explicitly marked with default visibility.
Fixes PR39236
Reviewers: hans, thakis
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D53052
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r348462 | lebedevri | 2018-12-06 00:14:24 -0800 (Thu, 06 Dec 2018) | 13 lines
[InstCombine] foldICmpWithLowBitMaskedVal(): don't miscompile -1 vector elts
I was finally able to quantify what i thought was missing in the fix,
it was vector constants. If we have a scalar (and %x, -1),
it will be instsimplified before we reach this code,
but if it is a vector, we may still have a -1 element.
Thus, we want to avoid the fold if *at least one* element is -1.
Or in other words, ignoring the undef elements, no sign bits
should be set. Thus, m_NonNegative().
A follow-up for rL348181
https://bugs.llvm.org/show_bug.cgi?id=39861
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r348461 | lebedevri | 2018-12-06 00:11:20 -0800 (Thu, 06 Dec 2018) | 4 lines
[NFC][InstCombine] Add more miscompile tests for foldICmpWithLowBitMaskedVal()
We also have to me aware of vector constants. If at least one element
is -1, we can't transform.
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r348181 | lebedevri | 2018-12-03 12:07:58 -0800 (Mon, 03 Dec 2018) | 8 lines
[InstCombine] foldICmpWithLowBitMaskedVal(): disable 2 faulty folds.
These two folds are invalid for this non-constant pattern
when the mask ends up being all-ones:
https://rise4fun.com/Alive/9au
https://rise4fun.com/Alive/UcQM
Fixes https://bugs.llvm.org/show_bug.cgi?id=39861
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r343369 | vitalybuka | 2018-09-28 19:17:12 -0700 (Fri, 28 Sep 2018) | 1 line
[cxx2a] Fix warning triggered by r343285
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r343369 | vitalybuka | 2018-09-28 19:17:12 -0700 (Fri, 28 Sep 2018) | 1 line
[cxx2a] Fix warning triggered by r343285
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r343369 | vitalybuka | 2018-09-28 19:17:12 -0700 (Fri, 28 Sep 2018) | 1 line
[cxx2a] Fix warning triggered by r343285
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r343369 | vitalybuka | 2018-09-28 19:17:12 -0700 (Fri, 28 Sep 2018) | 1 line
[cxx2a] Fix warning triggered by r343285
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r345470 | brad | 2018-10-27 20:30:18 -0700 (Sat, 27 Oct 2018) | 2 lines
Reapply Pass the nopie flag to the linker when linking with -pg.
------------------------------------------------------------------------
|
|
`aggressive-binary-operation-simplification` enabled
During the review of D41938 a condition check with an early exit accidentally
slipped into a branch, leaving the other branch unprotected. This may result in
an assertion later on. This hotfix moves this contition check outside of the
branch.
Differential Revision: https://reviews.llvm.org/D55051
|
|
------------------------------------------------------------------------
r343753 | phosek | 2018-10-03 22:38:53 -0700 (Wed, 03 Oct 2018) | 7 lines
[CMake] Use just basename when copying C++ ABI headers
This avoids duplicate directories when the filename includes path.
Fixes PR39145
Differential Revision: https://reviews.llvm.org/D52762
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r344100 | emaste | 2018-10-09 17:34:17 -0700 (Tue, 09 Oct 2018) | 16 lines
clang: Allow ifunc resolvers to accept arguments
When ifunc support was added to Clang (r265917) it did not allow
resolvers to take function arguments. This was based on GCC's
documentation, which states resolvers return a pointer and take no
arguments.
However, GCC actually allows resolvers to take arguments, and glibc (on
non-x86 platforms) and FreeBSD (on x86 and arm64) pass some CPU
identification information as arguments to ifunc resolvers. I believe
GCC's documentation is simply incorrect / out-of-date.
FreeBSD already removed the prohibition in their in-tree Clang copy.
Differential Revision: https://reviews.llvm.org/D52703
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r344589 | dstenb | 2018-10-16 01:06:48 -0700 (Tue, 16 Oct 2018) | 41 lines
[DebugInfo][LCSSA] Rewrite pre-existing debug values outside loop
Summary:
Extend LCSSA so that debug values outside loops are rewritten to
use the PHI nodes that the pass creates.
This fixes PR39019. In that case, we ran LCSSA on a loop that
was later on vectorized, which left us with something like this:
for.cond.cleanup:
%add.lcssa = phi i32 [ %add, %for.body ], [ %34, %middle.block ]
call void @llvm.dbg.value(metadata i32 %add,
ret i32 %add.lcssa
for.body:
%add =
[...]
br i1 %exitcond, label %for.cond.cleanup, label %for.body
which later resulted in the debug.value becoming undef when
removing the scalar loop (and the location would have probably
been wrong for the vectorized case otherwise).
As we now may need to query the AvailableVals cache more than
once for a basic block, FindAvailableVals() in SSAUpdaterImpl is
changed so that it updates the cache for blocks that we do not
create a PHI node for, regardless of the block's number of
predecessors. The debug value in the attached IR reproducer
would not be properly rewritten without this.
Debug values residing in blocks where we have not inserted any
PHI nodes are currently left as-is by this patch. I'm not sure
what should be done with those uses.
Reviewers: mattd, aprantl, vsk, probinson
Reviewed By: mattd, aprantl
Subscribers: jmorse, gbedwell, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D53130
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r339260 | syzaara | 2018-08-08 08:20:43 -0700 (Wed, 08 Aug 2018) | 13 lines
[PowerPC] Improve codegen for vector loads using scalar_to_vector
This patch aims to improve the codegen for vector loads involving the
scalar_to_vector (load X) sequence. Initially, ld->mv instructions were used
for scalar_to_vector (load X), so this patch allows scalar_to_vector (load X)
to utilize:
LXSD and LXSDX for i64 and f64
LXSIWAX for i32 (sign extension to i64)
LXSIWZX for i32 and f64
Committing on behalf of Amy Kwan.
Differential Revision: https://reviews.llvm.org/D48950
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r347556 | nemanjai | 2018-11-26 06:35:38 -0800 (Mon, 26 Nov 2018) | 11 lines
[PowerPC] Vector load/store builtins overstate alignment of pointers
A number of builtins in altivec.h load/store vectors from pointers to scalar
types. Currently they just cast the pointer to a vector pointer, but expressions
like that have the alignment of the target type. Of course, the input pointer
did not have that alignment so this triggers UBSan (and rightly so).
This resolves https://bugs.llvm.org/show_bug.cgi?id=39704
Differential revision: https://reviews.llvm.org/D54787
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r347431 | rnk | 2018-11-21 14:01:10 -0800 (Wed, 21 Nov 2018) | 12 lines
[mingw] Use unmangled name after the $ in the section name
GCC does it this way, and we have to be consistent. This includes
stdcall and fastcall functions with suffixes. I confirmed that a
fastcall function named "foo" ends up in ".text$foo", not
".text$@foo@8".
Based on a patch by Andrew Yohn!
Fixes PR39218.
Differential Revision: https://reviews.llvm.org/D54762
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r344444 | baloghadamsoftware | 2018-10-13 03:34:52 -0700 (Sat, 13 Oct 2018) | 11 lines
[clang-tidy] Optimize query in bugprone-exception-escape
Checking whether a functions throws indirectly may be very expensive because it
needs to visit its whole call graph. Therefore we should first check whether the
function is forbidden to throw and only check whether it throws afterward. This
also seems to solve bug https://bugs.llvm.org/show_bug.cgi?id=39167 where the
execution time is so long that it seems to hang.
Differential Revision: https://reviews.llvm.org/D53187
------------------------------------------------------------------------
------------------------------------------------------------------------
r344445 | baloghadamsoftware | 2018-10-13 04:17:59 -0700 (Sat, 13 Oct 2018) | 3 lines
[clang-tidy] Fix for typos in the tests for `bugprone-exception-escape`
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r345497 | asavonic | 2018-10-29 04:14:01 -0700 (Mon, 29 Oct 2018) | 29 lines
[OpenCL] Fix serialization of OpenCLExtensionDecls
Summary:
I recently discovered that adding the following code into `opencl-c.h` causes
failure of `test/Headers/opencl-c-header.cl`:
```
#pragma OPENCL EXTENSION cl_my_ext : begin
void cl_my_ext_foobarbaz();
#pragma OPENCL EXTENSIOn cl_my_ext : end
```
Clang crashes at the assertion is `ASTReader::getGlobalSubmoduleID()`:
```
assert(I != M.SubmoduleRemap.end() && "Invalid index into submodule index remap");
```
The root cause of the problem that to deserialize `OPENCL_EXTENSION_DECLS`
section `ASTReader` needs to deserialize a Decl contained in it. In turn,
deserializing a Decl requires information about whether this declaration is
part of a (sub)module, but this information is not read yet because it is
located further in a module file.
Reviewers: Anastasia, yaxunl, JDevlieghere
Reviewed By: Anastasia
Subscribers: sidorovd, cfe-commits, asavonic
Differential Revision: https://reviews.llvm.org/D53200
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r343105 | lebedevri | 2018-09-26 06:08:44 -0700 (Wed, 26 Sep 2018) | 17 lines
[analyzer] scan-build: if --status-bugs is passed, don't forget about the exit status of the actual build
Summary:
This has been bothering me for a while, but only now i have actually looked into this.
I'm using one CI job for static analysis - clang static analyzers as compilers + clang-tidy via cmake.
And i'd like for the build to fail if at least one of those finds issues.
If clang-tidy finds issues, it will fail the build since the warnings-as-errors is set.
If static analyzer finds anything, since --status-bugs is set, it will fail the build.
But if clang-tidy find anything, but static analyzer does not, the build succeeds :/
Reviewers: sylvestre.ledru, alexfh, jroelofs, ygribov, george.karpenkov, krememek
Reviewed By: jroelofs
Subscribers: xazax.hun, szepet, a.sidorin, mikhail.ramalho, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D52530
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r347179 | brad | 2018-11-18 16:21:06 -0800 (Sun, 18 Nov 2018) | 4 lines
[PowerPC] Set the default PLT mode on OpenBSD/powerpc to Secure PLT.
OpenBSD/powerpc only supports Secure PLT.
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r342865 | courbet | 2018-09-24 01:39:48 -0700 (Mon, 24 Sep 2018) | 11 lines
[llvm-exegesis] Fix PR39021.
Summary:
The `set` statements was incorrectly reading the value of the local variable and
setting the value of the parent variable.
Reviewers: tycho, gchatelet, john.brawn
Subscribers: mgorny, tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D52343
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r347262 | vedantk | 2018-11-19 12:10:22 -0800 (Mon, 19 Nov 2018) | 8 lines
[Coverage] Fix PR39258: support coverage regions that start deeper than they end
popRegions used to assume that the start location of a region can't be
nested deeper than the end location, which is not always true.
Patch by Orivej Desh!
Differential Revision: https://reviews.llvm.org/D53244
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r347261 | vedantk | 2018-11-19 12:10:21 -0800 (Mon, 19 Nov 2018) | 11 lines
[Sema] Fix PR38987: keep end location of a direct initializer list
If PerformConstructorInitialization of a direct initializer list constructor is
called while instantiating a template, it has brace locations in its BraceLoc
arguments but not in the Kind argument.
This reverts the hunk https://reviews.llvm.org/D41921#inline-468844.
Patch by Orivej Desh!
Differential Revision: https://reviews.llvm.org/D53231
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r345353 | sima | 2018-10-25 18:28:36 -0700 (Thu, 25 Oct 2018) | 21 lines
Teach the DominatorTree fallback to recalculation when applying updates to speedup JT (PR37929)
Summary:
This patch makes the dominatortree recalculate when applying updates with the size of the update vector larger than a threshold. Directly applying updates is usually slower than recalculating the whole domtree in this case. This patch fixes an issue which causes JT running slowly on some inputs.
In bug 37929, the dominator tree is trying to apply 19,000+ updates several times, which takes several minutes.
After this patch, the time used by DT.applyUpdates:
| Input | Before (s) | After (s) | Speedup |
| the 2nd Reproducer in 37929 | 297 | 0.15 | 1980x |
| clang-5.0.0.0.bc | 9.7 | 4.3 | 2.26x |
| clang-5.0.0.4.bc | 11.6 | 2.6 | 4.46x |
Reviewers: kuhar, brzycki, trentxintong, davide, dmgreen, grosser
Reviewed By: kuhar, brzycki
Subscribers: kristina, llvm-commits
Differential Revision: https://reviews.llvm.org/D53245
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r341697 | arphaman | 2018-09-07 11:59:45 -0700 (Fri, 07 Sep 2018) | 4 lines
warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'
Addresses first post-commit feedback for r335081 from Nico
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r344605 | jankratochvil | 2018-10-16 04:38:22 -0700 (Tue, 16 Oct 2018) | 12 lines
Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), function ExtractDIEsRWLocked
xbolva00 bugreported $subj in: https://reviews.llvm.org/D46810#1247410
It can happen only from the line:
m_die_array.back().SetEmptyChildren(true);
In the case DW_TAG_compile_unit has DW_CHILDREN_yes but there is only 0 (end of
list, no children present). Therefore the assertion can fortunately happen only
with a hand-crafted DWARF or with DWARF from some suboptimal compilers.
Differential Revision: https://reviews.llvm.org/D53255
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r344591 | abeserminji | 2018-10-16 01:27:28 -0700 (Tue, 16 Oct 2018) | 11 lines
[mips][micromips] Fix how values in .gcc_except_table are calculated
When a landing pad is calculated in a program that is compiled
for micromips, it will point to an even address. Such an error will
cause a segmentation fault, as the instructions in micromips are
aligned on odd addresses. This patch sets the last bit of the offset
where a landing pad is, to 1, which will effectively be
an odd address and point to the instruction exactly.
Differential Revision: https://reviews.llvm.org/D52985
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r343212 | meinersbur | 2018-09-27 06:39:37 -0700 (Thu, 27 Sep 2018) | 37 lines
[IslAst] Fix InParallelFor nesting.
IslAst could mark two nested outer loops as "OutermostParallel". It
caused that the code generator tried to OpenMP-parallelize both loops,
which it is not prepared loop.
It was because the recursive AST build algorithm managed a flag
"InParallelFor" to ensure that no nested loop is also marked as
"OutermostParallel". Unfortunatetly the same flag was used by nodes
marked as SIMD, and reset to false after the SIMD node. Since loops can
be marked as SIMD inside "OutermostParallel" loops, the recursive
algorithm again tried to mark loops as "OutermostParellel" although
still nested inside another "OutermostParallel" loop.
The fix exposed another bug: The function "astScheduleDimIsParallel" was
only called when a loop was potentially "OutermostParallel" or
"InnermostParallel", but as a side-effect also determines the minimum
dependence distance. Hence, changing when we need to know whether a loop
is "OutermostParallel" also changed which loop was annotated with
"#pragma minimal dependence distance".
Moreover, some complex condition linked with "InParallelFor" determined
whether a loop should be an "InnermostParallel" loop. It missed some
situations where it would not use mark as such although being inside an
SIMD mark node, and therefore not be annotated using "#pragma simd".
The changes in particular:
1. Split the "InParallelFor" flag into an "InParallelFor" and an
"InSIMD" flag.
2. Unconditionally call "astScheduleDimIsParallel" for its side-effects
and store the result in "InParallel" for later use.
3. Simplify the condition when a loop is "InnermostParallel".
Fixes llvm.org/PR33153 and llvm.org/PR38073.
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r344516 | abeserminji | 2018-10-15 07:39:12 -0700 (Mon, 15 Oct 2018) | 12 lines
[mips][micromips] Fix overlaping FDEs error
When compiling static executable for micromips, CFI symbols
are incorrectly labeled as MICROMIPS, which cause
".eh_frame_hdr refers to overlapping FDEs." error.
This patch does not label CFI symbols as MICROMIPS, and FDEs do not
overlap anymore. This patch also exposes another bug, which is fixed
here: https://reviews.llvm.org/D52985
Differential Revision: https://reviews.llvm.org/D52987
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r342946 | smaksimovic | 2018-09-24 23:27:49 -0700 (Mon, 24 Sep 2018) | 6 lines
[mips] Correct MUL pattern for mips64
Guard existing pattern with a predicate, introduce a new one for revision 6.
Differential Revision: https://reviews.llvm.org/D51684
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r342884 | petarj | 2018-09-24 07:14:19 -0700 (Mon, 24 Sep 2018) | 12 lines
[Mips][FastISel] Fix selectBranch on icmp i1
The r337288 tried to fix result of icmp i1 when its input is not sanitized
by falling back to DagISel. While it now produces the correct result for
bit 0, the other bits can still hold arbitrary value which is not supported
by MipsFastISel branch lowering. This patch fixes the issue by falling back
to DagISel in this case.
Patch by Dragan Mladjenovic.
Differential Revision: https://reviews.llvm.org/D52045
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r341919 | atanasyan | 2018-09-11 02:57:25 -0700 (Tue, 11 Sep 2018) | 18 lines
[mips] Add a pattern for 64-bit GPR variant of the `rdhwr` instruction
MIPS ISAs start to support third operand for the `rdhwr` instruction
starting from Revision 6. But LLVM generates assembler code with
three-operands version of this instruction on any MIPS64 ISA. The third
operand is always zero, so in case of direct code generation we get
correct code.
This patch fixes the bug by adding an instruction alias. The same alias
already exists for 32-bit ISA.
Ideally, we also need to reject three-operands version of the `rdhwr`
instruction in an assembler code if ISA revision is less than 6. That is
a task for a separate patch.
This fixes PR38861 (https://bugs.llvm.org/show_bug.cgi?id=38861)
Differential revision: https://reviews.llvm.org/D51773
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r341221 | atanasyan | 2018-08-31 08:57:17 -0700 (Fri, 31 Aug 2018) | 12 lines
[mips] Fix `mtc1` and `mfc1` definitions for microMIPS R6
The `mtc1` and `mfc1` definitions in the MipsInstrFPU.td have MMRel,
but do not have StdMMR6Rel tags. When these instructions are emitted
for microMIPS R6 targets, `Mips::MipsR62MicroMipsR6` nor
`Mips::Std2MicroMipsR6` cannot find correct op-codes and as a result the
backend uses mips32 variant of the instructions encoding.
The patch fixes this problem by adding the StdMMR6Rel tag and check
instructions encoding in the test case.
Differential revision: https://reviews.llvm.org/D51482
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r340932 | atanasyan | 2018-08-29 07:54:01 -0700 (Wed, 29 Aug 2018) | 11 lines
[mips] Fix microMIPS unconditional branch offset handling
MipsSEInstrInfo class defines for internal purpose unconditional
branches as Mips::B nad Mips:J even in case of microMIPS code
generation. Under some conditions that leads to the bug - for rather long
branch which fits to Mips jump instruction offset size, but does not fit
to microMIPS jump offset size, we generate 'short' branch and later show
an error 'out of range PC16 fixup' after check in the isBranchOffsetInRange
routine.
Differential revision: https://reviews.llvm.org/D50615
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r340931 | atanasyan | 2018-08-29 07:53:55 -0700 (Wed, 29 Aug 2018) | 6 lines
[mips] Involves microMIPS's jump in the analyzable branch set
Involves microMIPS's jump in the analyzable branch set to reduce some
code patterns.
Differential revision: https://reviews.llvm.org/D50613
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r340927 | vstefanovic | 2018-08-29 07:07:14 -0700 (Wed, 29 Aug 2018) | 14 lines
[mips] Prevent shrink-wrap for BuildPairF64, ExtractElementF64 when they use $sp
For a certain combination of options, BuildPairF64_{64}, ExtractElementF64{_64}
may be expanded into instructions using stack.
Add implicit operand $sp for such cases so that ShrinkWrapping doesn't move
prologue setup below them.
Fixes MultiSource/Benchmarks/MallocBench/cfrac for
'--target=mips-img-linux-gnu -mcpu=mips32r6 -mfpxx -mnan=2008'
and
'--target=mips-img-linux-gnu -mcpu=mips32r6 -mfp64 -mnan=2008 -mno-odd-spreg'.
Differential Revision: https://reviews.llvm.org/D50986
------------------------------------------------------------------------
|
|
|
|
------------------------------------------------------------------------
r342354 | kristina | 2018-09-16 15:21:59 -0700 (Sun, 16 Sep 2018) | 11 lines
[DebugInfo] Fix build when std::vector::iterator is a pointer
std::vector::iterator type may be a pointer, then
iterator::value_type fails to compile since iterator is not a class,
namespace, or enumeration.
Patch by orivej (Orivej Desh)
Differential Revision: https://reviews.llvm.org/D52142
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r344454 | xbolva00 | 2018-10-13 08:21:55 -0700 (Sat, 13 Oct 2018) | 11 lines
[InstCombine] Fixed crash with aliased functions
Summary: Fixes PR39177
Reviewers: spatel, jbuening
Reviewed By: jbuening
Subscribers: jbuening, llvm-commits
Differential Revision: https://reviews.llvm.org/D53129
------------------------------------------------------------------------
------------------------------------------------------------------------
r344455 | xbolva00 | 2018-10-13 08:26:13 -0700 (Sat, 13 Oct 2018) | 2 lines
[NFC] Fixed duplicated test file
------------------------------------------------------------------------
------------------------------------------------------------------------
r344645 | xbolva00 | 2018-10-16 14:18:31 -0700 (Tue, 16 Oct 2018) | 9 lines
[InstCombine] Cleanup libfunc attribute inferring
Reviewers: efriedma
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53338
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r341312 | psmith | 2018-09-03 05:36:32 -0700 (Mon, 03 Sep 2018) | 13 lines
[Aarch64] Fix linker emulation for Aarch64 big endian
This patch fixes target linker emulation for aarch64 big endian.
aarch64_be_linux is not recognized by gnu ld. The equivalent emulation
mode supported by gnu ld is aarch64linuxb.
Patch by: Bharathi Seshadri
Reviewed by: Peter Smith
Differential Revision: https://reviews.llvm.org/D42930
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r345002 | dim | 2018-10-22 22:53:15 -0700 (Mon, 22 Oct 2018) | 41 lines
Don't mess up RelIplt symbols during relocatable processing
Summary:
During upgrading of the FreeBSD source tree with lld 7.0.0, I noticed
that it started complaining about `crt1.o` having an "index past the
end of the symbol table".
Such a symbol table looks approximately like this, viewed with `readelf
-s` (note the `Ndx` field being messed up):
```
Symbol table '.symtab' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_end
3: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_start
```
At first, it seemed that recent ifunc relocation work had caused this:
<https://reviews.freebsd.org/rS339351>, but it turned out that it was
due to incorrect processing of the object files by lld, when using `-r`
(a.k.a. --relocatable).
Bisecting showed that rL324421 ("Convert a use of Config->Static") was
the commit where this new behavior began. Simply reverting it solved
the issue, and the `__rel_iplt` symbols had an index of `UND` again.
Looking at Rafael's commit message, I think he simply missed the
possibility of `--relocatable` being in effect, so I have added an
additional check for it.
I also added a simple regression test case.
Reviewers: grimar, ruiu, emaste, espindola
Reviewed By: ruiu
Subscribers: arichardson, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D53515
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r343669 | grimar | 2018-10-03 02:59:08 -0700 (Wed, 03 Oct 2018) | 6 lines
[ELF] - Fix BB after r343668
This stops testing the value of .rela.plt section offset.
Also makes _start global to eliminate
'cannot find entry symbol _start' warning.
------------------------------------------------------------------------
|
|
------------------------------------------------------------------------
r341778 | rsmith | 2018-09-09 23:35:32 -0700 (Sun, 09 Sep 2018) | 5 lines
PR33222: Require the declared return type not the actual return type to
match when checking for redeclaration of a function template.
This properly handles differences in deduced return types, particularly
when performing redeclaration checks for a friend function template.
------------------------------------------------------------------------
|
