History log of /freebsd-12.1/contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp (Results 1 – 10 of 10)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0
# b5893f02 12-Apr-2019 Dimitry Andric <[email protected]>

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.0 final release r356365.

MFC r340287 (by emaste):

Consolidate gcov entries in OptionalObsoleteFiles

Sponsored by: The Fr

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.0 final release r356365.

MFC r340287 (by emaste):

Consolidate gcov entries in OptionalObsoleteFiles

Sponsored by: The FreeBSD Foundation

MFC r340289 (by emaste):

llvm-cov: also install as gcov (if GNU gcov is disabled)

llvm-cov provides a gcov-compatible interface when invoked as gcov.

Reviewed by: dim, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17923

MFC r340296 (by emaste):

Move llvm-profdata build into MK_LLVM_COV block

llvm-profdata is used with llvm-cov for code coverage (although llvm-cov
can also operate independently in a gcov-compatible mode).
Although llvm-profdata can be used independently of llvm-cov it makes
sense to group these under one option.

Also handle these in OptionalObsoleteFiles.inc while here.

Sponsored by: The FreeBSD Foundation

MFC r340300 (by emaste):

libllvm: Move SampleProfWriter to SRCS_MIN

It is required by llvm-profdata, now built by default under the
LLVM_COV knob. The additional complexity that would come from avoiding
building it if CLANG_EXTRAS and LLVM_COV are both disabled is not worth
the small savings in build time.

Sponsored by: The FreeBSD Foundation

MFC r340972 (by emaste):

llvm-objdump: initial man page

Based on llvm-objdump's online documentation and usage information.
This serves as a starting point; additional detail and cleanup still
required.

Also being submitted upstream in LLVM review D54864. I expect to use
this bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when we
update to LLVM 8.0 it should be upstream and we will switch to it.

PR: 233437
Reviewed by: bcr (man formatting)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18309

MFC r340973 (by emaste):

llvm-objdump.1: remove invalid options

Some options appear in llvm-objdump's usage information as a side effect
of its option parsing implementation and are not actually llvm-objdump
options. Reported in LLVM review https://reviews.llvm.org/D54864.

Reported by: Fangrui Song
Sponsored by: The FreeBSD Foundation

MFC r340975 (by emaste):

llvm-objdump.1: fix igor / mandoc -Tlint warnings

Accidentally omitted from r340972.

MFC r341055 (by emaste):

llvm-objdump.1: remove more unintentional options

Some options come from static constructors in LLVM libraries and are
automatically added to llvm's usage output. They're not really supposed
to be llvm-objdump options.

Reported by: Fangrui Song in LLVM review D54864
Sponsored by: The FreeBSD Foundation

MFC r344779:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The
release will follow very soon, but no more functional changes are
expected.

Release notes for llvm, clang and lld 8.0.0 will soon be available here:
<https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html>
<https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html>
<https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html>

PR: 236062
Relnotes: yes

MFC r344798 (by emaste):

libllvm: promote WithColor and xxhash to SRCS_MIN

The armv6 build failed in CI due to missing symbols (from these two
source files) in the bootstrap Clang.

This affected only armv6 because other Clang-using archs are using LLD
as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP.

Reported by: CI, via lwhsu
Sponsored by: The FreeBSD Foundation

MFC r344825:

Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwise
clang and various other executables will fail to link with undefined
symbols.

Reported by: O. Hartmann <[email protected]>

MFC r344852:

Put in a temporary workaround for what is likely a gcc 6 bug (it does
not occur with gcc 7 or later). This should prevent the following error
from breaking the head-amd64-gcc CI builds:

In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0:
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
using std::vector<lldb_private::MemoryRegionInfo>::vector;
^~~~~~
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'

Reported by: CI

MFC r344896:

Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger):

Fix inline assembler constraint validation

The current constraint logic is both too lax and too strict. It fails
for input outside the [INT_MIN..INT_MAX] range, but it also
implicitly accepts 0 as value when it should not. Adjust logic to
handle both correctly.

Differential Revision: https://reviews.llvm.org/D58649

Pull in r355491 from upstream clang trunk (by Hans Wennborg):

Inline asm constraints: allow ICE-like pointers for the "n"
constraint (PR40890)

Apparently GCC allows this, and there's code relying on it (see bug).

The idea is to allow expression that would have been allowed if they
were cast to int. So I based the code on how such a cast would be
done (the CK_PointerToIntegral case in
IntExprEvaluator::VisitCastExpr()).

Differential Revision: https://reviews.llvm.org/D58821

These should fix assertions and errors when using the inline assembly
"n" constraint in certain ways.

In case of devel/valgrind, a pointer was used as the input for the
constraint, which lead to "Assertion failed: (isInt() && "Invalid
accessor"), function getInt".

In case of math/secp256k1, a very large integer value was used as input
for the constraint, which lead to "error: value '4624529908474429119'
out of range for constraint 'n'".

PR: 236216, 236194

MFC r344951:

Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch
r355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump version
numbers.

PR: 236062

MFC r345018:

Merge LLVM libunwind trunk r351319, from just before upstream's
release_80 branch point. Afterwards, we will merge the rest of the
changes in the actual release_80 branch.

PR: 236062

MFC r345019:

Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4).

PR: 236062

MFC r345021:

Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):

[RegAlloc] Avoid compile time regression with multiple copy hints.

As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive
compile time building opencollada"), this patch makes sure that no
phys reg is hinted more than once from getRegAllocationHints().

This handles the case were many virtual registers are assigned to the
same physreg. The previous compile time fix (r343686) in
weightCalcHelper() only made sure that physical/virtual registers are
passed no more than once to addRegAllocationHint().

Review: Dimitry Andric, Quentin Colombet
https://reviews.llvm.org/D59201

This should fix a hang when compiling certain generated .cpp files in
the graphics/opencollada port.

PR: 236313

MFC r345068 (by jhb):

Move libunwind out of contrib/llvm/projects.

Move LLVM's libunwind to its own contrib/ directory similar to other
runtime libraries like libc++ and libcxxrt.

Reviewed by: dim, emaste
Differential Revision: https://reviews.freebsd.org/D19534

MFC r345073:

Revert r308867 (which was originally committed in the clang390-import
project branch):

Work around LLVM PR30879, which is about a bad interaction between
X86 Call Frame Optimization on i386 and libunwind, by disallowing the
optimization for i386-freebsd12.

This should fix some instances of broken exception handling when
frame pointers are omitted, in particular some unittests run during
the build of editors/libreoffice.

This hack will be removed as soon as upstream has implemented a more
permanent fix for this problem.

And indeed, after r345018 and r345019, which updated LLVM libunwind to
the most recent version, the above workaround is no longer needed. The
upstream commit which fixed this is:

https://llvm.org/viewvc/llvm-project?view=revision&revision=292723

Specifically, 32 bit (i386-freebsd) executables optimized with omitted
frame pointers and Call Frame Optimization should now behave correctly
when a C++ exception is thrown, and the stack is unwound.

Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879
PR: 236062

MFC r345152:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb
release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts,
and bump version numbers.

PR: 236062

MFC r345231:

Add LLVM openmp trunk r351319 (just before the release_80 branch point)
to contrib/llvm. This is not yet connected to the build, the glue for
that will come in a follow-up commit.

PR: 236062

MFC r345232:

Bootstrap svn:mergeinfo on contrib/openmp.

PR: 236062

MFC r345233:

Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5).

PR: 236062

MFC r345234:

Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3).
This has also been submitted upstream.

PR: 236062

MFC r345283:

Enable building libomp.so for 32-bit x86. This is done by selectively
enabling the functions that save and restore MXCSR, since access to this
register requires SSE support.

Note that you may run into other issues with OpenMP on i386, since this
*not* yet supported upstream, and certainly not extensively tested.

PR: 236062, 236582

MFC r345345:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.0 final release r356365. There were no functional changes since the
most recent merge, of 8.0.0 rc5.

Release notes for llvm, clang, lld and libc++ 8.0.0 are now available:

https://llvm.org/releases/8.0.0/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.html

PR: 236062

MFC r345349:

Pull in r352826 from upstream lld trunk (by Fangrui Song):

[ELF] Support --{,no-}allow-shlib-undefined

Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when
linking an executable. This patch implements a check to error on
undefined symbols in a shared object, if all of its DT_NEEDED entries
are seen.

Our approach resembles the one used in gold, achieves a good balance
to be useful but not too smart (ld.bfd traces all DSOs and emulates
the behavior of a dynamic linker to catch more cases).

The error is issued based on the symbol table, different from
undefined reference errors issued for relocations. It is most
effective when there are DSOs that were not linked with -z defs (e.g.
when static sanitizers runtime is used).

gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.

Reviewers: ruiu, grimar, pcc, espindola

Reviewed By: ruiu

Subscribers: joerg, emaste, arichardson, llvm-commits

Differential Revision: https://reviews.llvm.org/D57385

Pull in r352943 from upstream lld trunk (by Fangrui Song):

[ELF] Default to --no-allow-shlib-undefined for executables

Summary:
This follows the ld.bfd/gold behavior.

The error check is useful as it captures a common type of ld.so
undefined symbol errors as link-time errors:

// a.cc => a.so (not linked with -z defs)
void f(); // f is undefined
void g() { f(); }

// b.cc => executable with a DT_NEEDED entry on a.so
void g();
int main() { g(); }

// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now)
// symbol lookup error: ... undefined symbol: f

Reviewers: ruiu, grimar, pcc, espindola

Reviewed By: ruiu

Subscribers: llvm-commits, emaste, arichardson

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57569

Together, these add support for --no-allow-shlib-undefined, and make it
the default for executables, so they will fail to link if any symbols
from needed shared libraries are undefined.

Reported by: jbeich
PR: 236062, 236141

MFC r345449:

Pull in r356809 from upstream llvm trunk (by Eli Friedman):

[ARM] Don't form "ands" when it isn't scheduled correctly.

In r322972/r323136, the iteration here was changed to catch cases at
the beginning of a basic block... but we accidentally deleted an
important safety check. Restore that check to the way it was.

Fixes https://bugs.llvm.org/show_bug.cgi?id=41116

Differential Revision: https://reviews.llvm.org/D59680

This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking
is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe
port for armv7.

PR: 236062, 236568

show more ...


# 4ba319b5 16-Feb-2019 Dimitry Andric <[email protected]>

Merge clang 7.0.1 and several follow-up changes

MFC r341825:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_70 branch r348686 (effectively, 7.0.1 rc3).

Merge clang 7.0.1 and several follow-up changes

MFC r341825:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The
release will follow very soon, but no more functional changes are
expected.

Release notes for llvm, clang and lld 7.0.0 are available here:
<http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html>

PR: 230240, 230355
Relnotes: yes

MFC r342123:

Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to
7.0.1 release r349250. There were no functional changes since the 7.0.1
rc3 import.

PR: 230240, 230355
Relnotes: yes

r343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 lines

clang: default to DWARF 4 as of FreeBSD 13

FreeBSD previously defaulted to DWARF 2 because several tools (gdb,
ctfconvert, etc.) did not support later versions. These have either
been fixed or are deprecated.

Note that gdb 6 still exists but has been moved out of $PATH into
/usr/libexec and is intended only for use by crashinfo(8). The kernel
build sets the DWARF version explicitly via -gdwarf2, so this should
have no effect there.

PR: 234887 [exp-run]
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17930

MFC r343916:

Pull in r352607 from upstream llvm trunk (by Craig Topper):

[X86] Add FPSW as a Def on some FP instructions that were missing it.

Pull in r353141 from upstream llvm trunk (by Craig Topper):

[X86] Connect the default fpsr and dirflag clobbers in inline
assembly to the registers we have defined for them.

Summary:
We don't currently map these constraints to physical register numbers
so they don't make it to the MachineIR representation of inline
assembly.

This could have problems for proper dependency tracking in the
machine schedulers though I don't have a test case that shows that.

Reviewers: rnk

Reviewed By: rnk

Subscribers: eraman, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57641

Pull in r353489 from upstream llvm trunk (by Craig Topper):

[X86] Add FPCW as a register and start using it as an implicit use on
floating point instructions.

Summary:
FPCW contains the rounding mode control which we manipulate to
implement fp to integer conversion by changing the roudning mode,
storing the value to the stack, and then changing the rounding mode
back. Because we didn't model FPCW and its dependency chain, other
instructions could be scheduled into the middle of the sequence.

This patch introduces the register and adds it as an implciit def of
FLDCW and implicit use of the FP binary arithmetic instructions and
store instructions. There are more instructions that need to be
updated, but this is a good start. I believe this fixes at least the
reduced test case from PR40529.

Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor

Subscribers: dim, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D57735

These should fix a problem in clang 7.0 where it would sometimes emit
long double floating point instructions in a slightly wrong order,
leading to failures in our libm tests. In particular, the cbrt_test
test case 'cbrtl_powl' and the trig_test test case 'reduction'.

Also bump __FreeBSD_cc_version, to be able to detect this in our test
suite.

Reported by: lwhsu
PR: 234040
Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40206

MFC r344056:

Pull in r339734 from upstream llvm trunk (by Eli Friedman):

[ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly.

Intentionally excluding nodes from the DAGCombine worklist is likely
to lead to weird optimizations and infinite loops, so it's generally
a bad idea.

To avoid the infinite loops, fix DAGCombine to use the
isDesirableToCommuteWithShift target hook before performing the
transforms in question, and implement the target hook in the ARM
backend disable the transforms in question.

Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a
reduced testcase for that bug. But we should have sufficient test
coverage for PerformSHLSimplify given that we're not playing weird
tricks with the worklist. I can try to bugpoint it if necessary,
though.)

Differential Revision: https://reviews.llvm.org/D50667

This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c
(which exists now only in the stable/11 branch) for arm.

show more ...


# b19b6cc7 16-Jan-2019 Dimitry Andric <[email protected]>

Pull in r337861 from upstream llvm trunk (by Hideki Saito):

[LV] Fix for PR38110, LV encountered llvm_unreachable()

Summary: truncateToMinimalBitWidths() doesn't handle all Instructions
and t

Pull in r337861 from upstream llvm trunk (by Hideki Saito):

[LV] Fix for PR38110, LV encountered llvm_unreachable()

Summary: truncateToMinimalBitWidths() doesn't handle all Instructions
and the worst case is compiler crash via llvm_unreachable(). Fix is
to add a case to handle PHINode and changed the worst case to NO-OP
(from compiler crash).

Reviewers: sbaranga, mssimpso, hsaito

Reviewed By: hsaito

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D49461

This should fix "Unhandled instruction type!" (if assertions are
enabled) or segmentation faults (if assertions are disabled) when
compiling certain versions of the net-p2p/gtk-gnutella port.

Direct commit to stable/11 and stable/12, since head already has this
fix.

Reported by: Jamie Landeg-Jones <[email protected]>
PR: 234987

show more ...


Revision tags: release/12.0.0, release/11.2.0
# a7264ff5 15-Jan-2018 Dimitry Andric <[email protected]>

Pull in r322473 from upstream llvm trunk (by Andrei Elovikov):

[LV] Don't call recordVectorLoopValueForInductionCast for
newly-created IV from a trunc.

Summary:
This method is supposed to b

Pull in r322473 from upstream llvm trunk (by Andrei Elovikov):

[LV] Don't call recordVectorLoopValueForInductionCast for
newly-created IV from a trunc.

Summary:
This method is supposed to be called for IVs that have casts in their
use-def chains that are completely ignored after vectorization under
PSE. However, for truncates of such IVs the same InductionDescriptor
is used during creation/widening of both original IV based on PHINode
and new IV based on TruncInst.

This leads to unintended second call to
recordVectorLoopValueForInductionCast with a VectorLoopVal set to the
newly created IV for a trunc and causes an assert due to attempt to
store new information for already existing entry in the map. This is
wrong and should not be done.

Fixes PR35773.

Reviewers: dorit, Ayal, mssimpso

Reviewed By: dorit

Subscribers: RKSimon, dim, dcaballe, hsaito, llvm-commits, hiraditya

Differential Revision: https://reviews.llvm.org/D41913

This should fix "Vector value already set for part" assertions when
building the net/iodine and sysutils/daa2iso ports.

Reported by: jbeich
PR: 224867,224868

show more ...


Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0
# f8789c6b 29-May-2016 Dimitry Andric <[email protected]>

Pull in r269908 from upstream llvm trunk (by James Molloy):

[VectorUtils] Fix nasty use-after-free

In truncateToMinimalBitwidths() we were RAUW'ing an instruction then
erasing it. However, th

Pull in r269908 from upstream llvm trunk (by James Molloy):

[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

show more ...


Revision tags: release/10.3.0, release/10.2.0
# 292d912a 09-Dec-2014 Dimitry Andric <[email protected]>

Pull in r223171 from upstream llvm trunk (by Michael Zolotukhin):

PR21302. Vectorize only bottom-tested loops.

rdar://problem/18886083

This fixes a bug in the llvm vectorizer, which could some

Pull in r223171 from upstream llvm trunk (by Michael Zolotukhin):

PR21302. Vectorize only bottom-tested loops.

rdar://problem/18886083

This fixes a bug in the llvm vectorizer, which could sometimes cause
vectorized loops to perform an additional iteration, leading to possible
buffer overruns. Symptoms of this, which are usually segfaults, were
first noticed when building gcc ports, here:

https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.html
https://lists.freebsd.org/pipermail/freebsd-toolchain/2014-September/001211.html

Note: because this is applied on top of llvm/clang 3.5.0, this fix is
slightly different from the one just checked into head in r275633.

show more ...


# cd952115 09-Dec-2014 Dimitry Andric <[email protected]>

Pull in r223171 from upstream llvm trunk (by Michael Zolotukhin):

PR21302. Vectorize only bottom-tested loops.

rdar://problem/18886083

This fixes a bug in the llvm vectorizer, which could some

Pull in r223171 from upstream llvm trunk (by Michael Zolotukhin):

PR21302. Vectorize only bottom-tested loops.

rdar://problem/18886083

This fixes a bug in the llvm vectorizer, which could sometimes cause
vectorized loops to perform an additional iteration, leading to possible
buffer overruns. Symptoms of this, which are usually segfaults, were
first noticed when building gcc ports, here:

https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.html
https://lists.freebsd.org/pipermail/freebsd-toolchain/2014-September/001211.html

Since this fix is very important for ports, bump __FreeBSD_version to
make it easier for port maintainers to test whether the fix has been
applied.

Upstream PR: http://llvm.org/PR21302
MFC after: 3 days

show more ...


Revision tags: release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0
# b3eb0ffb 26-May-2013 Dimitry Andric <[email protected]>

Pull in r182656 from upstream llvm trunk:

LoopVectorize: LoopSimplify can't canonicalize loops with an
indirectbr in it, don't assert on those cases.

Fixes PR16139.

This should fix clang ass

Pull in r182656 from upstream llvm trunk:

LoopVectorize: LoopSimplify can't canonicalize loops with an
indirectbr in it, don't assert on those cases.

Fixes PR16139.

This should fix clang assertion failures when optimizing at -O3, similar
to:

Assertion failed: (TheLoop->getLoopPreheader() && "No preheader!!"),
function canVectorize, file
contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp, line 2171.

Reported by: O. Hartmann <[email protected]>
PR: ports/178332, ports/178977
MFC after: 3 days

show more ...


# 779aaa55 13-May-2013 Dimitry Andric <[email protected]>

Pull in r181286 from upstream llvm trunk:

LoopVectorize: getConsecutiveVector must respect signed arithmetic

We were passing an i32 to ConstantInt::get where an i64 was needed and we must
als

Pull in r181286 from upstream llvm trunk:

LoopVectorize: getConsecutiveVector must respect signed arithmetic

We were passing an i32 to ConstantInt::get where an i64 was needed and we must
also pass the sign if we pass negatives numbers. The start index passed to
getConsecutiveVector must also be signed.

Should fix PR15882.

This should fix Firefox crashes some people have been reporting, when it
is compiled with -O3.

show more ...


# 5c47cd66 23-Apr-2013 Dimitry Andric <[email protected]>

Pull in r180121 from upstream llvm trunk:

LoopVectorizer: Fix 15830. When scalarizing and unrolling stores make
sure that the order in which the elements are scalarized is the same
as the orig

Pull in r180121 from upstream llvm trunk:

LoopVectorizer: Fix 15830. When scalarizing and unrolling stores make
sure that the order in which the elements are scalarized is the same
as the original order.
This fixes a miscompilation in FreeBSD's regex library.

This should fix lib/libc/regex/regcomp.c at -O3 with clang 3.3 r178860
on CPUs with SSE. Before this change, the vectorizer could incorrectly
rearrange the second loop in computejumps(), leading to possibly invalid
entries in the re_gets::charjump table.

The net result was that for example "sed s/@CC@/foo/" failed to work
correctly, leading to trouble with many configure scripts.

show more ...