[x86] don't try to create a vector integer inst for an SSE1 target
(PR30512)
This bug was introduced with:
http://reviews.llvm.org/rL272511
We need to restrict the lowering to v4f32 comparisons because that's
all SSE1 can handle.
This should fix:
https://llvm.org/bugs/show_bug.cgi?id=28044
This avoids a "Do not know how to custom type legalize this operation"
error when building the multimedia/ffmpeg port on i386 with SSE enabled.
[PPC] Claim stack frame before storing into it, if no red zone is
present
Unlike PPC64, PPC32/SVRV4 does not have red zone. In the absence of
it there is no guarantee that this part of the stack will not be
modified by any interrupt. To avoid this, make sure to claim the
stack frame first before storing into it.
This fixes https://llvm.org/bugs/show_bug.cgi?id=26519.
Differential Revision: https://reviews.llvm.org/D24093
Add ISD::EH_DWARF_CFA, simplify @llvm.eh.dwarf.cfa on Mips, fix on
PowerPC
LLVM has an @llvm.eh.dwarf.cfa intrinsic, used to lower the
GCC-compatible __builtin_dwarf_cfa() builtin. As pointed out in
PR26761, this is currently broken on PowerPC (and likely on ARM as
well). Currently, @llvm.eh.dwarf.cfa is lowered using:
ADD(FRAMEADDR, FRAME_TO_ARGS_OFFSET)
where FRAME_TO_ARGS_OFFSET defaults to the constant zero. On x86,
FRAME_TO_ARGS_OFFSET is lowered to 2*SlotSize. This setup, however,
does not work for PowerPC. Because of the way that the stack layout
works, the canonical frame address is not exactly (FRAMEADDR +
FRAME_TO_ARGS_OFFSET) on PowerPC (there is a lower save-area offset
as well), so it is not just a matter of implementing
FRAME_TO_ARGS_OFFSET for PowerPC (unless we redefine its semantics --
We can do that, since it is currently used only for
@llvm.eh.dwarf.cfa lowering, but the better to directly lower the CFA
construct itself (since it can be easily represented as a
fixed-offset FrameIndex)). Mips currently does this, but by using a
custom lowering for ADD that specifically recognizes the (FRAMEADDR,
FRAME_TO_ARGS_OFFSET) pattern.
This change introduces a ISD::EH_DWARF_CFA node, which by default
expands using the existing logic, but can be directly lowered by the
target. Mips is updated to use this method (which simplifies its
implementation, and I suspect makes it more robust), and updates
PowerPC to do the same.
Fixes PR26761.
Differential Revision: https://reviews.llvm.org/D24038
[PowerPC] Don't spill the frame pointer twice
When a function contains something, such as inline asm, which
explicitly clobbers the register used as the frame pointer, don't
spill it twice. If we need a frame pointer, it will be saved/restored
in the prologue/epilogue code. Explicitly spilling it again will
reuse the same spill slot used by the prologue/epilogue code, thus
clobbering the saved value. The same applies to the base-pointer or
PIC-base register.
Partially fixes PR26856. Thanks to Ulrich for his analysis and the
small inline-asm reproducer.
[PowerPC] Add support for -mlongcall
The "long call" option forces the use of the indirect calling
sequence for all calls (even those that don't really need it). GCC
provides this option; This is helpful, under certain circumstances,
for building very-large binaries, and some other specialized use
cases.
Fixes PR19098.
Pull in r280041 from upstream clang trunk (by Hal Finkel):
[PowerPC] Add support for -mlongcall
Add support for GCC's PowerPC -mlongcall option; the backend supports
the corresponding target feature as of r280040.
Fixes PR19098.
Don't reduce the width of vector mul if the target doesn't support
SSE2.
The patch is to fix PR30298, which is caused by rL272694. The
solution is to bail out if the target has no SSE2.
Differential Revision: https://reviews.llvm.org/D24288
This fixes building the multimedia/libx264 port on i386.
[AArch64] Return the correct size for TLSDESC_CALLSEQ
The branch relaxation pass is computing the wrong offsets because it assumes
TLSDESC_CALLSEQ eats up 4 bytes, when in fact it is lowered to an instruction
sequence taking up 16 bytes. This can become a problem in huge files with lots
of TLS accesses, as it may slowly move branch targets out of the range computed
by the branch relaxation pass.
Fixes PR24234 https://llvm.org/bugs/show_bug.cgi?id=24234
Differential Revision: https://reviews.llvm.org/D22870
This fixes "error in backend: fixup value out of range" when compiling
the misc/talkfilters port for AArch64.
Reported by: sbruno
PR: 201762
MFC after: 3 days
positive diagnostics from -Wvarargs about enum parameters, e.g.:
cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c:388:15: error: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior
[-Werror,-Wvarargs]
va_start(ap, which);
^
cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c:382:66: note: parameter of type 'enum nvlist_prtctl_fmt' is declared here
nvlist_prtctl_dofmt(nvlist_prtctl_t pctl, enum nvlist_prtctl_fmt which, ...)
^
Fix for pr24346: arm asm label calculation error in sub
Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:
add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260
would be assembled to the following, which adds 1 to r0, instead of
260:
e2800104 add r0, r0, #4, 2 ; equivalently 1
The new fixup kind fixup_arm_mod_imm takes care of the encoding:
e2800f41 add r0, r0, #260
Patch by Ting-Yuan Huang!
This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.
Requested by: jkim
MFC after: 3 days
[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE
btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.
Differential Revision: http://reviews.llvm.org/D17682
Pull in r262782 from upstream llvm trunk (by Simon Pilgrim):
[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE
btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.
Differential Revision: http://reviews.llvm.org/D17683
This ensures clang does not emit AVX instructions for CPUTYPE=btver1.
Reported by: Michel Depeige <demik+freebsd@lostwave.net>
PR: 211864
MFC after: 3 days
_Unwind_Exception is required to be double word aligned. GCC has
interpreted this to mean "use the maximum useful alignment for the
target" so follow that lead.
Obtained from: LLVM review D22543
FreeBSD uses LLVM's libunwind on FreeBSD/arm64 today (and we expect to
use it more widely in the future) and it requires the EH frame segment
in static binaries.
Reviewed by: dim
Obtained from: Clang commit r266123
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7250
For historical reasons Darwin/i386 has ebp and esp swapped in the
eh_frame register numbering. That is:
Darwin Other
Reg # eh_frame eh_frame DWARF
===== ======== ======== =====
4 ebp esp esp
5 esp ebp ebp
Although the UNW_X86_* constants are not supposed to be coupled to
DWARF / eh_frame numbering they are currently conflated in LLVM
libunwind, and thus we require the non-Darwin numbering.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
This may be reworked upstream but in the interim should address the
stack usage issue reported in the PR.
PR: 206384
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The key improvement is that it may be built without cross-unwinding
support, which significantly reduces the stack space requirement.
MFC after: 1 week
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7123
Only attempt to detect AVG if SSE2 is available
Summary:
In PR29973 Sanjay Patel reported an assertion failure when a certain
loop was optimized, for a target without SSE2 support. It turned out
this was because of the AVG pattern detection introduced in rL253952.
Prevent the assertion failure by bailing out early in
`detectAVGPattern()`, if the target does not support SSE2.
Also add a minimized test case.
Reviewers: congh, eli.friedman, spatel
Subscribers: emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D20905
This should fix assertion failures ("Requires at least SSE2!") when
building the games/0ad port with CPUTYPE=pentium3.
Reported by: madpilot
[VectorUtils] Fix nasty use-after-free
In truncateToMinimalBitwidths() we were RAUW'ing an instruction then
erasing it. However, that intruction could be cached in the map we're
iterating over. The first check is "I->use_empty()" which in most
cases would return true, as the (deleted) object was RAUW'd first so
would have zero use count. However in some cases the object could
have been polluted or written over and this wouldn't be the case.
Also it makes valgrind, asan and traditionalists who don't like their
compiler to crash sad.
No testcase as there are no externally visible symptoms apart from a
crash if the stars align.
Fixes PR26509.
This should fix crashes when building a number of ports on arm64.
Reported by: andrew
Make __FreeBSD_cc_version predefined macro configurable at build time
The `FreeBSDTargetInfo` class has always set the `__FreeBSD_cc_version`
predefined macro to a rather static value, calculated from the major OS
version.
In the FreeBSD base system, we will start incrementing the value of this
macro whenever we make any signifant change to clang, so we need a way
to configure the macro's value at build time.
Use `FREEBSD_CC_VERSION` for this, which we can define in the FreeBSD
build system using either the `-D` command line option, or an include
file. Stock builds will keep the earlier value.
Differential Revision: http://reviews.llvm.org/D20037
Follow-up commits will start using the __FreeBSD_cc_version to determine
whether a bootstrap compiler has to be built during buildworld.
Pass dwarf-version to cc1as.
Fix PR26999 - crashing in cc1as with any '*bsd' target.
This should fix possible crashes when using -g in combination with
-save-temps.
[X86] Emit a proper ADJCALLSTACKDOWN in EmitLoweredTLSAddr
We forgot to add the second machine operand to our ADJCALLSTACKDOWN,
resulting in crashes in PEI.
This fixes PR27071.
This should fix an assertion failure during buildworld, when using -Os,
and targeting either i386 directly, or building the 32-bit libraries on
amd64.
Reported by: Eric Camachat <eric.camachat@gmail.com>
Add <atomic> to ThreadPool.h, since std::atomic is used
Summary:
Apparently, when compiling with gcc 5.3.2 for powerpc64, the order of
headers is such that it gets an error about std::atomic<> use in
ThreadPool.h, since this header is not included explicitly. See also:
https://llvm.org/bugs/show_bug.cgi?id=27058
Fix this by including <atomic>. Patch by Bryan Drewery.
Reviewers: chandlerc, joker.eph
Subscribers: bdrewery, llvm-commits
Differential Revision: http://reviews.llvm.org/D18460
the safe point to insert the prologue and epilogue of the function) on
X86. This prevents problems with some functions using TLS, such as in
jemalloc, and which was the cause for Address Sanitizer crashes. The
correct fix is still being discussed upstream.
Fix PR26134: When substituting into default template arguments, keep
CurContext unchanged.
Or, do not set Sema's CurContext to the template declaration's when
substituting into default template arguments of said template
declaration.
If we do push the template declaration context on to Sema, and the
template declaration is at namespace scope, Sema can get confused and
try and do odr analysis when substituting into default template
arguments, even though the substitution could be occurring within a
dependent context.
I'm not sure why this was being done, perhaps there was concern that
if a default template argument referred to a previous template
parameter, it might not be found during substitution - but all
regression tests pass, and I can't craft a test that would cause it
to fails (if some one does, please inform me, and i'll craft a
different fix for the PR).
This patch removes a single line of code, but unfortunately adds more
than it removes, because of the tests. Some day I still hope to
commit a patch that removes far more lines than it adds, while
leaving clang better for it ;)
Sorry that r253590 ("Change the expression evaluation context from
Unevaluated to ConstantEvaluated while substituting into non-type
template argument defaults") caused the PR!
This fix will be merged to the upstream release_38 branch soon, but we
need it now, to fix a failure in the databases/sfcgal port.
[DwarfDebug] Move MergeValues to .cpp, NFC
Pull in r257979 from upstream llvm trunk, by Keno Fischer:
[DwarfDebug] Don't merge DebugLocEntries if their pieces overlap
Summary:
Later in DWARF emission we check that DebugLocEntries have
non-overlapping pieces, so we should create any such entries
by merging here.
Fixes PR26163.
Reviewers: aprantl
Differential Revision: http://reviews.llvm.org/D16249
Again, these will be merged to the official release_38 branch soon, but
we need them ASAP.
be merged to the official release_38 branch soon, but we need it ASAP):
Stop increasing alignment of externally-visible globals on ELF
platforms.
With ELF, the alignment of a global variable in a shared library will
get copied into an executables linked against it, if the executable even
accesss the variable. So, it's not possible to implicitly increase
alignment based on access patterns, or you'll break existing binaries.
This happened to affect libc++'s std::cout symbol, for example. See
thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311
(This is a re-commit of r257719, without the bug reported in
PR26144. I've tweaked the code to not assert-fail in
enforceKnownAlignment when computeKnownBits doesn't recurse far enough
to find the underlying Alloca/GlobalObject value.)
Differential Revision: http://reviews.llvm.org/D16145
was not recognized anymore for arm targets. Fix this by adding the
correct sub-arch to the xscale definition in ARMTargetParser.def. This
fix (from Andrew Turner) has also been submitted upstream.
llvm's LinkAllPasses.h. This caused some of the calls not to be
emitted, if the optimization level was -O2 or higher.
Conversely, if you used -O1 or lower, calls to e.g. RunningOnValgrind()
would be emitted, leading to link failures, because we did not include
Valgrind.cpp into libllvmsupport. Therefore, add it unconditionally.
Noticed by: ian
from upstream clang trunk, which sets the default debug tuning back to
gdb. The lldb debug tuning is not yet grokked completely by our ELF
manipulation tools.
As with previous imports a number of plugins not immediately relevant
to FreeBSD have been excluded:
ABIMacOSX_i386
ABIMacOSX_arm
ABIMacOSX_arm64
ABISysV_hexagon
AppleObjCRuntimeV2
AppleObjCRuntimeV1
SystemRuntimeMacOSX
RenderScriptRuntime
GoLanguageRuntime
GoLanguage
ObjCLanguage
ObjCPlusPlusLanguage
ObjectFilePECOFF
DynamicLoaderWindowsDYLD
platform_linux
platform_netbsd
PlatformWindows
PlatformKalimba
platform_android
DynamicLoaderMacOSXDYLD
ObjectContainerUniversalMachO
PlatformRemoteiOS
PlatformMacOSX
OperatingSystemGo
printed with -v. We have historically put a date stamp there (roughly
corresponding to the date of import), but this has never been used for
anything, and the patch has also never been upstreamed, so let's get rid
of it now.
bugfix-only release, with no new features.
Please note that from 3.5.0 onwards, clang and llvm require C++11
support to build; see UPDATING for more information.
breakpoint. The value doesn't need to be adjusted as it is already
correctly returned from the kernel.
This allows lldb to set breakpoints, and stop on them, however more work
is needed, for example single stepping fails to stop.
Discussed with: emaste
Change this to DWARF2, in the simplest way possible. (Upstream, this
was fixed in clang trunk r250173, but this was done along with a lot of
shuffling around of debug option handling, so it cannot be applied
as-is.)
Noticed by: des
MFC after: 3 days
Refactor library decision for -fopenmp support from Darwin into a
function for sharing with other platforms.
Pull in r248424 from upstream clang trunk (by Jörg Sonnenberger):
Push OpenMP linker flags after linker input on Darwin. Don't add any
libraries if -nostdlib is specified. Test.
Pull in r248426 from upstream clang trunk (by Jörg Sonnenberger):
Support linking against OpenMP runtime on NetBSD.
Pull in r250657 from upstream clang trunk (by Dimitry Andric):
Support linking against OpenMP runtime on FreeBSD.
[x86] Fix wrong lowering of vsetcc nodes (PR25080).
Function LowerVSETCC (in X86ISelLowering.cpp) worked under the wrong
assumption that for non-AVX512 targets, the source type and destination type
of a type-legalized setcc node were always the same type.
This assumption was unfortunately incorrect; the type legalizer is not always
able to promote the return type of a setcc to the same type as the first
operand of a setcc.
In the case of a vsetcc node, the legalizer firstly checks if the first input
operand has a legal type. If so, then it promotes the return type of the vsetcc
to that same type. Otherwise, the return type is promoted to the 'next legal
type', which, for vectors of MVT::i1 is always a 128-bit integer vector type.
Example (-mattr=+avx):
%0 = trunc <8 x i32> %a to <8 x i23>
%1 = icmp eq <8 x i23> %0, zeroinitializer
The initial selection dag for the code above is:
v8i1 = setcc t5, t7, seteq:ch
t5: v8i23 = truncate t2
t2: v8i32,ch = CopyFromReg t0, Register:v8i32 %vreg1
t7: v8i32 = build_vector of all zeroes.
The type legalizer would firstly check if 't5' has a legal type. If so, then it
would reuse that same type to promote the return type of the setcc node.
Unfortunately 't5' is of illegal type v8i23, and therefore it cannot be used to
promote the return type of the setcc node. Consequently, the setcc return type
is promoted to v8i16. Later on, 't5' is promoted to v8i32 thus leading to the
following dag node:
v8i16 = setcc t32, t25, seteq:ch
where t32 and t25 are now values of type v8i32.
Before this patch, function LowerVSETCC would have wrongly expanded the setcc
to a single X86ISD::PCMPEQ. Surprisingly, ISel was still able to match an
instruction. In our case, ISel would have matched a VPCMPEQWrr:
t37: v8i16 = X86ISD::VPCMPEQWrr t36, t25
However, t36 and t25 are both VR256, while the result type is instead of class
VR128. This inconsistency ended up causing the insertion of COPY instructions
like this:
%vreg7<def> = COPY %vreg3; VR128:%vreg7 VR256:%vreg3
Which is an invalid full copy (not a sub register copy).
Eventually, the backend would have hit an UNREACHABLE "Cannot emit physreg copy
instruction" in the attempt to expand the malformed pseudo COPY instructions.
This patch fixes the problem adding the missing logic in LowerVSETCC to handle
the corner case of a setcc with 128-bit return type and 256-bit operand type.
This problem was originally reported by Dimitry as PR25080. It has been latent
for a very long time. I have added the minimal reproducible from that bugzilla
as test setcc-lowering.ll.
Differential Revision: http://reviews.llvm.org/D13660
This should fix the "Cannot emit physreg copy instruction" errors when
compiling contrib/wpa/src/common/ieee802_11_common.c, and CPUTYPE is set
to a CPU supporting AVX (e.g. sandybridge, ivybridge).
[SLP] Vectorize for all-constant entries.
This should fix libc++'s iostream initialization SIGBUSing on amd64,
whenever the global cout symbol is not aligned to 16 bytes.
Some further explanation: libc++'s iostream.cpp contains the definitions
of std::cout, std::cerr and so on. These global objects are effectively
declared with an alignment of 8 bytes. When an executable is linked
against libc++.so, it can sometimes get a copy of the global object,
which is then at the same alignment.
However, with clang 3.7.0, the initialization of these global objects
will incorrectly use SSE instructions (e.g. movdqa), whenever the
optimization level is high enough, and SSE is enabled, such as on amd64.
When any of these objects is not aligned to 16 bytes, this will result
in a SIGBUS during iostream initialization. In contrast, clang 3.6.x
and earlier took the 8 byte alignment into consideration, and avoided
SSE for those particular operations.
After bisecting of upstream changes, I found that the above revision
caused the change of this behavior, so I am reverting it now as a
workaround, while a discussion and test case is being prepared for
upstream.
set div/rem default values to 'expensive' in TargetTransformInfo's
cost model
...because that's what the cost model was intended to do.
As discussed in D12882, this fix has a temporary unintended
consequence for SimplifyCFG: it causes us to not speculate an fdiv.
However, two wrongs make PR24818 right, and two wrongs make PR24343
act right even though it's really still wrong.
I intend to correct SimplifyCFG and add to CodeGenPrepare to account
for this cost model change and preserve the righteousness for the bug
report cases.
https://llvm.org/bugs/show_bug.cgi?id=24818https://llvm.org/bugs/show_bug.cgi?id=24343
Differential Revision: http://reviews.llvm.org/D12882
This fixes the too-eager fdiv hoisting in pow(), which could lead to
unexpected floating point exceptions.
Add missing atomic libcall support.
Support for emitting libcalls for __atomic_fetch_nand and
__atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some
test cases.
Differential Revision: http://reviews.llvm.org/D10847
This fixes "cannot compile this atomic library call yet" errors when
compiling code which calls the above builtins, on arm < v6.
