Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an email with the SVN revision in trunk and also cc the code owner and llvm-commits (or cfe-commits if it is a clang patch). - Start integrating the 3.4 branch into your project or OS distribution to and check for any issues. - Volunteer as a tester for the testing phase. Thank you, Tom
Hi, As proposed I'd do testing on OS X (10.9). Cheers, Sebastian> Am 26.03.2014 um 17:10 schrieb Tom Stellard <tom at stellard.net>: > > Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I would > like to start preparing for a 3.4.1 release. Here is my proposed release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. > April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, send > me an email with the SVN revision in trunk and also cc the code owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase. > > Thank you, > > Tom
On 26 March 2014 16:25, Sebastian Dreßler <sebastian.dressler at gmail.com> wrote:> As proposed I'd do testing on OS X (10.9).Same here, Linux on ARMv7. cheers, -renato
Still happy to test. Due to the timing, I can test/package both Ubuntu 13.10 and 14.04 on x64 (running 14.04 at home, 13.10 in the office) Although 14.04 is due for final freeze April 10 and release April 17, we'll see how it goes. Ben On 27 Mar 2014 00:10, "Tom Stellard" <tom at stellard.net> wrote:> Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I would > like to start preparing for a 3.4.1 release. Here is my proposed release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 > branch. > April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, send > me an email with the SVN revision in trunk and also cc the code owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase. > > Thank you, > > Tom >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140327/b28648ec/attachment.html>
I can do building+testing on OSX 10.9 and ARM, building and basic testing on OSX 10.8 and 10.7, and build-only on win32 (does win64 work?). You can pick and choose :-) -- Erik> On 26 mrt. 2014, at 17:10, Tom Stellard <tom at stellard.net> wrote: > > Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I would > like to start preparing for a 3.4.1 release. Here is my proposed release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. > April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, send > me an email with the SVN revision in trunk and also cc the code owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase. > > Thank you, > > Tom
I can do building+testing on Ubuntu 12.04/x86_64. Cheers, -- Arnaud On Wed, Mar 26, 2014 at 6:23 PM, Erik Verbruggen <erik.verbruggen at me.com>wrote:> I can do building+testing on OSX 10.9 and ARM, building and basic testing > on OSX 10.8 and 10.7, and build-only on win32 (does win64 work?). > > You can pick and choose :-) > > -- Erik > > > > On 26 mrt. 2014, at 17:10, Tom Stellard <tom at stellard.net> wrote: > > > > Hi, > > > > We are now about halfway between the 3.4 and 3.5 releases, and I would > > like to start preparing for a 3.4.1 release. Here is my proposed release > > schedule: > > > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 > branch. > > April 9 - April 18: Testing Phase > > April 18: 3.4.1 Release > > > > How you can help: > > > > - If you have any bug fixes you think should be included to 3.4.1, send > > me an email with the SVN revision in trunk and also cc the code owner > > and llvm-commits (or cfe-commits if it is a clang patch). > > > > - Start integrating the 3.4 branch into your project or OS distribution > > to and check for any issues. > > > > - Volunteer as a tester for the testing phase. > > > > Thank you, > > > > Tom >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140326/6207455d/attachment.html>
----- Original Message -----> From: "Tom Stellard" <tom at stellard.net> > To: llvmdev at cs.uiuc.edu > Cc: "Renato Golin" <renato.golin at linaro.org>, "Sylvestre Ledru" <sylvestre at debian.org>, "Sebastian Dreßler" > <sebastian.dressler at gmail.com>, "Hal Finkel" <hfinkel at anl.gov>, "Ben Pope" <benpope81 at gmail.com>, "Arnaud Allard de > Grandmaison" <arnaud.adegm at gmail.com>, "Erik Verbruggen" <erik.verbruggen at me.com> > Sent: Wednesday, March 26, 2014 11:10:43 AM > Subject: 3.4.1 Release Plans > > Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I > would > like to start preparing for a 3.4.1 release. Here is my proposed > release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the > 3.4 branch. > April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, > send > me an email with the SVN revision in trunk and also cc the code > owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS > distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase.I'll go through the commit list shortly; also I'll help with testing on (X86 and PPC64). Thanks again for working on this! -Hal> > Thank you, > > Tom >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On Wed, Mar 26, 2014 at 9:10 AM, Tom Stellard <tom at stellard.net> wrote:> Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I would > like to start preparing for a 3.4.1 release. Here is my proposed release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. > April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, send > me an email with the SVN revision in trunk and also cc the code owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase.I can test and package on Windows. - Hans
Hello, could I just ask a few questions regarding the 3.4.1 release? I am interested whether it will be available on the LLVM website the same way as regular 3.X releases? Also, if I understand correctly, this release is only a bugfixing release based on 3.4, right? Thank you Adam On Wed, 26 Mar 2014 17:10:43 +0100, Tom Stellard <tom at stellard.net> wrote:> Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I would > like to start preparing for a 3.4.1 release. Here is my proposed release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 > branch. > April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, send > me an email with the SVN revision in trunk and also cc the code owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase. > > Thank you, > > Tom > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Fri, Mar 28, 2014 at 10:03 AM, ihusar at fit.vutbr.cz <ihusar at fit.vutbr.cz>wrote:> Hello, > > could I just ask a few questions regarding the 3.4.1 release? > > I am interested whether it will be available on the LLVM website the same > way as > regular 3.X releases? > >Yes.> Also, if I understand correctly, this release is only a bugfixing release > based on 3.4, > right? > >Correct. Thank you> Adam > > > > > On Wed, 26 Mar 2014 17:10:43 +0100, Tom Stellard <tom at stellard.net> wrote: > > Hi, >> >> We are now about halfway between the 3.4 and 3.5 releases, and I would >> like to start preparing for a 3.4.1 release. Here is my proposed release >> schedule: >> >> Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 >> branch. >> April 9 - April 18: Testing Phase >> April 18: 3.4.1 Release >> >> How you can help: >> >> - If you have any bug fixes you think should be included to 3.4.1, send >> me an email with the SVN revision in trunk and also cc the code owner >> and llvm-commits (or cfe-commits if it is a clang patch). >> >> - Start integrating the 3.4 branch into your project or OS distribution >> to and check for any issues. >> >> - Volunteer as a tester for the testing phase. >> >> Thank you, >> >> Tom >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140328/ae66b364/attachment.html>
On 26/03/2014 17:10, Tom Stellard wrote:> Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I would > like to start preparing for a 3.4.1 release. Here is my proposed release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. > April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, send > me an email with the SVN revision in trunk and also cc the code owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase. > >Count me in! FYI, the lastest builds are available here: http://llvm.org/apt/ for most Debian and Ubuntu versions. It would be nice if someone could have a look to this bug: http://llvm.org/bugs/show_bug.cgi?id=16821 For the release. Cheers, Sylvestre
Hi Tom,
We want the following patches go into release 3.4.1.
Clang:
196750 [AArch64]Add missing pair intrinsics such as: int32_t
vminv_s32(int32x2_t a)
196834 [AArch64] Remove q and non-q intrinsic definitions from the NEON
scalar reduce pairwise implementation, using an overloaded definition
instead.
196835 [AArch64] Refactor the NEON scalar reduce pairwise front-end codegen
to remove unnecessary patterns in tablegen.
196836 [AArch64] Refactor the NEON scalar reduce pairwise intrinsics so
that they use float/double rather than the vector equivalents when
appropriate.
196888 [AArch64 NEON] Support poly128_t and implement relevant intrinsic.
196927 [AArch64] Refactor the Neon vector/scalar floating-point convert
implementation. Specifically, reuse the ARM intrinsics when possible.
196931 [AArch64] Refactor the Neon vector/scalar floating-point convert
intrinsics so that they use float/double rather than the vector equivalents
when appropriate.
196936 [AArch64] Refactor the redundant code in the
EmitAArch64ScalarBuiltinExpr() function. No functional change intended.
196966 [AArch64] Overload NEON signed/unsigned integer convert to
floating-point LLVM AArch64 intrinsics.
196967 [AArch64] Overload NEON signed/unsigned floating-point convert to
fixed-point and fixed-point convert to floating-point LLVM AArch64
intrinsics.
196968 [AArch64] Refactor the NEON signed/unsigned floating-point convert
to fixed-point LLVM AArch64 intrinsics to use f32/f64, rather than their
vector equivalents.
196969 [AArch64] Refactor the NEON floating-point absolute difference LLVM
AArch64 intrinsic to use f32/f64 types, rather than their vector
equivalents.
197069 [AArch64] Refactor the NEON scalar floating-point reciprocal
estimate, floating-point reciprocal exponent, and floating-point reciprocal
square root estimate
197070 [AArch64] Refactor the NEON scalar floating-point reciprocal step
and floating-point reciprocal square root step LLVM AArch64 intrinsics to
197071 [AArch64] Add NEON scalar floating-point compare LLVM AArch64
intrinsics that use f32/f64 types, rather than their vector equivalents.
197091 [AArch64] Refactor NEON floating-point Max/Min/Maxnm/Minnm across
vector AArch64 intrinsics to use f32 types, rather than their vector
equivalents.
197112 [AArch64] Fix Incorrect CHECK message [0-31]+ in test case.
197403 [AArch64] Fix v1fx patterns for Floating-point Multiply Extend and
Floating-point Compare to Zero.
197898 [AArch64] The compare to zero intrinsics should be implemented by
'icmp/fcmp' and 'sext' not 'zext'. Modify the
implementation by replacing
zext with sext.
197994 [AArch64] Add some missing test cases for ACLE intrinsics of AArch64
NEON.
198195 [AArch64] For AArch64 Neon, simplify scalar dup by lane0 for fp.
198741 [AArch64] For AArch64, support builtin neon vector type with
'long'
as base element type.
199866 [AArch64 NEON] Fix a bug about vcles_f32 and vcled_f64.
200114 [AArch64] For AArch64 Neon, fix intrinsics implementation using
nested macros.
200470 ARM & AArch64: share the BI__builtin_neon enum defs.
200471 ARM & AArch64: fully share NEON implementation of permutation
intrinsics
200472 ARM & AArch64: extend shared NEON implementation to first block.
200524 ARM & AArch64: merge another NEON block completely.
200525 ARM & AArch64: more instructions into common block
200526 ARM & AArch64: move shared vld/vst intrinsics to common
implementation.
200527 ARM & AArch64: another block of miscellaneous NEON sharing.
200528 ARM & AArch64: unify the rest of the completely shared NEON
implementations
200707 [AArch64] AArch64: use new non-polymorphic crypto intrinsics This
was caused by r200708 which enabled the crypto feature for these cores.
200708 ARM: implement support for crypto intrinsics in arm_neon.h
200769 ARM & AArch64: combine implementation of vcaXYZ intrinsics
201112 [AArch64] Fixed vget/vset_lane_f16 implementation
201384 [AArch64] Enable AArch64 NEON by default.
202004 [AArch64] Change int64_t from 'long long int' to 'long
int' for
AArch64 target.
LLVM:
196748 [AArch64]Pattern match failures for truncate store and extend load
196749 [AArch64]Add missing pair intrinsics such as: int32_t
vminv_s32(int32x2_t a)
196831 [AArch64] Remove q and non-q intrinsic definitions in the NEON
scalar reduce pairwise implementation, using an overloaded definition
instead.
196832 [AArch64] Refactor NEON scalar reduce pairwise front-end codegen to
remove unnecessary patterns in tablegen.
196833 [AArch64] Refactor the NEON scalar reduce pairwise intrinsics, so
that they use float/double rather than the vector equivalents when
appropriate.
196887 [AArch64 NEON] Support poly128_t and implement relevant intrinsic.
196889 [AArch64 NEON] Replace fpimm with fpz32 for floating compare with
zero. This is a small change to be strict. Just want get pattern safer.
196926 [AArch64] Refactor the Neon vector/scalar floating-point convert
implementation. Specifically, reuse the ARM intrinsics when possible.
196930 [AArch64] Refactor the Neon vector/scalar floating-point convert
intrinsics so that they use float/double rather than the vector equivalents
when appropriate.
196962 [AArch64] Overload NEON signed/unsigned integer convert to
floating-point LLVM AArch64 intrinsics.
196963 [AArch64] Overload NEON signed/unsigned floating-point convert to
fixed-point and fixed-point convert to floating-point LLVM AArch64
intrinsics.
196964 [AArch64] Refactor the NEON signed/unsigned floating-point convert
to fixed-point LLVM AArch64 intrinsics to use f32/f64, rather than their
vector equivalents.
196965 [AArch64] Refactor the NEON floating-point absolute difference LLVM
AArch64 intrinsic to use f32/f64 types, rather than their vector
equivalents.
196998 [AArch64 NEON] Get instruction BSL matched to VSELECT.
197066 [AArch64] Refactor the NEON scalar floating-point reciprocal
estimate, floating- point reciprocal exponent, and floating-point
reciprocal square root estimate
197067 [AArch64] Refactor the NEON scalar floating-point reciprocal step
and floating-point reciprocal square root step LLVM AArch64 intrinsics to
197068 [AArch64] Add NEON scalar floating-point compare LLVM AArch64
intrinsics that use f32/f64 types, rather than their vector equivalents.
197090 [AArch64] Refactor NEON floating-point Max/Min/Maxnm/Minnm across
vector AArch64 intrinsics to use f32 types, rather than their vector
equivalents.
197113 Fix Incorrect CHECK message [0-31]+ in test case. In regular
expression, [0-31]+ equals to [0-3]+, not the number from
197135 [AArch64]Fix the problem that AArch64 backend fails to select
scalar_to_vector of vector types having more than one element.
197159 [AArch64] Removed unnecessary copy patterns with v1fx types.
197250 [AArch64] Simplify the Neon Scalar3Same patterns for floating-point
reciprocal step, floating-point reciprocal square root step, floating-point
absolute
197361 [AArch64]Fix the pattern match failure for v1i8/v1i16/v1i32 types.
Currently we have such types as legal vector types. The DAG combiner may
generate some DAG nodes having such types but we don't have patterns to
match them.
197402 [AArch64] Fix v1fx patterns for Floating-point Multiply Extend and
Floating-point Compare to Zero.
197551 [AArch64 NEON]Implment loading vector constant form constant pool.
197897 [AArch64]The compare to zero intrinsics should be implemented by
'icmp/fcmp' and 'sext' not 'zext'. Modify the test
cases.
197928 [AArch64 NEON] Fixed fused multiply negate add/sub patterns
197929 [AArch64] Check fmul node single use in fused multiply patterns
197966 [AArch64 NEON] Fix a pattern match failure with NEON_VDUP.
197967 [AArch64 NEON] Fix a bug when lowering BUILD_VECTOR.
197969 [AArch64]Add patterns to match normal shift nodes: shl, sra and srl.
197993 Add missing pattern matches to support ACLE intrinsics of AArch64
NEON.
198001 [AArch64]Fix a problem that the register order of fmls/fmla by
element is incorrect.
198084 Teach DAGCombiner how to fold a SIGN_EXTEND_INREG of a BUILD_VECTOR
of ConstantSDNodes (or UNDEFs) into a simple BUILD_VECTOR.
198188 [AArch64]Fix the problem that can't select mul of v1i64/v2i64 types.
198190 Fix a bug in DAGcombiner about zero-extend after setcc.
198192 [AArch64]Can't select shift left 0 of type v1i64
198193 [AArch64]Add code to spill/fill Q register tuples such as
QPair/QTriple/QQuad.
198194 For AArch64 Neon, simplify scalar dup by lane0 for fp.
198437 [AArch64][NEON] Added SXTL and SXTL2 instruction aliases
198675 [AArch64 NEON] Fixed incorrect immediate used in BIC instruction.
198682 [AArch64]Add support to copy D tuples such as DPair/DTriple/DQuad
and Q tuples such as QPair/QTriple/QQuad. There is no test case for D tuple
as the original test cases are too large. As the copy of the D tuple is
similar to the Q tuple, the correctness can be guaranteed.
198684 [AArch64]Add support to spill/fill D tuples such as
DPair/DTriple/DQuad. There is no test cases for D tuple as the original
test cases are too large. As the spill/fill of the D tuple is similar to
the Q tuple, the correctness can be guaranteed.
198730 Fix a bug about generating undef operand when optimising shuffle
vector and insert element in instruction combine.
198743 [AArch64 NEON] Fix generating incorrect value type of NEON_VDUPLANE
when lower build_vector if result value type mismatch with operand
198791 [AArch64][NEON] Added UXTL and UXTL2 instruction aliases
198937 Make sure -use-init-array has intended effect on all AArch64 ELF
targets, not just linux.
198941 Silence unused variable warning for non-asserting builds that was
introduced in r198937.
199069 [AArch64 NEON] Add more scenarios to use perm instructions when
lowering shuffle_vector
199070 [AArch64 NEON] Add missing patterns for bitcast from or to v1f64
199242 [AArch64] Added vselect patterns with float and double types
199296 For AArch64, lowering sext_inreg and generate optimized code by
using SXTL.
199369 For ARM, fix assertuib failures for some ld/st 3/4 instruction with
wirteback.
199461 [AArch64]Fix the problem can't select concat_vectors of two v1i32
types. Also fix the problem can't select scalar_to_vector from f32 to
v2f32/v4f32.
199462 [AArch64 NEON] Custom lower conversion between vector integer and
vector floating point if element bit-width doesn't match.
199463 [AArch64]Fix the problem can't select f16_to_f32 and f32_to_f16.
Also add copy support for FPR16.
199485 [AArch64 NEON] Expand vector for UDIV/SDIV/UREM/SREM/FREM as neon
doesn't support these operations.
199621 [AArch64 NEON] Accept both #0.0 and #0 for comparing with floating
point zero in asm parser.
199628 [AArch64 NEON] Fix a bug caused by undef lane when generating VEXT.
199631 Revert r199628: "[AArch64 NEON] Fix a bug caused by undef lane when
generating VEXT."
199791 [AArch64 NEON] Try to generate CONCAT_VECTOR when lowering
BUILD_VECTOR or SHUFFLE_VECTOR.
199858 fix some spell mistakes around 'ConcatVector' and
'ShuffleVector' in
AArch64 backend.
199861 [AArch64]Add CHECK for two test cases testing scalar_to_vector
committed in r199461.
199978 [AArch64 NEON] Fix a bug in implementing register copy bwtween FPR16.
200109 [AArch64 NEON] Fix pattern match failed on FP_ROUND from v1f128 to
v1f64.
200110 [AArch64 NEON] Add test case for vector FP_ROUND.
200111 [AArch64 NEON] Add patterns for concat_vector on v2i32.
200113 Implement pattern match from v1xx to v1xx for AArch64 Neon.
200119 Improve pattern match from v1i8 to v1i32 for AArch64 Neon.
200179 Revert r199791.
200180 [AArch64 NEON] Try to generate CONCAT_VECTOR when lowering
BUILD_VECTOR or SHUFFLE_VECTOR.
200365 [AArch64 NEON] Lower SELECT_CC with vector operand.
200491 [AArch64] Custom lower concat_vector patterns with v4i16, v4i32,
v8i8, v8i16, v16i8 types.
200706 AArch64 & ARM: refactor crypto intrinsics to take scalars
200768 ARM & AArch64: merge NEON absolute compare intrinsics
201061 [AArch64]Implement the copy of two FPR8 registers by using FMOVss of
two FPR32 registers in copyPhysReg.
201091 [AArch64] Handle aliases of conditional branches without b.pred form.
201287 [AArch64]Add support for spilling FPR8/FPR16.
201298 [AArch64]Fix the problems that can't select mul/add/sub of
v1i8/v1i16/v1i32 types. As this problems are similar to shl/sra/srl, also
add patterns for shift nodes.
201381 [AArch64]Fix the assertion failure caused by "v1i1 SETCC" DAG
node.
As v1i1 is illegal, the type legalizer tries to scalarize such node. But
if the type operands of SETCC is legal, the scalarization algorithm will
cause an assertion failure.
201385 Enable AArch64 NEON by default.
201395 [AArch64 NEON] Fix a bug to avoid using floating type as condition
type in lowering SELECT_CC.
201541 Fix a typo about lowering AArch64 va_copy.
201793 [AArch64] Add support for TargetTransformInfo Analysis.
201841 [AArch64] Add register constraints to avoid generating STLXR and
STXR with unpredictable behavior.
202775 [AArch64]Fix improper diagnostics about offset range of load/store
instructions.
204304 [ARM]Fix an assertion failure in A15SDOptimizer about DPair reg
class by treating DPair as QPR.
204424 [AArch64] Remove .data_region directive from AArch64.
I know the patch list is little bit longer, we have the following reasons,
1) Last year, when branch 3.4 was created, actually we didn't really have
time to complete all AArch64 neon work. So branch 3.4 is actually at the
middle stage of aarch64 neon implementation. Now the patches I'm requesting
intends to give a complete AArch64 NEON feature.
2) There are several critical bug fixes solving compiler crash issue, and
our end-user really want them to be fixed in new release, and end-user
can't wait until release 3.5.
3) A lot of patches are interleaved and have dependence one another, so
it's easy to introduce bug if do cherry picking only for some of them.
The patches I listed are in time ordering, so it's easy for you to apply
them to branch 3.4. There are only the following failures, but it's easy to
be fixed,
1) 200708: Only need to manually add line "Features["crypto"] =
true;"
after line 5924 of file lib/Basic/Targets.cpp
2) 201384: Manually add two lines below after line 7135 of
file lib/Driver/Tools.cpp
else
Features.push_back("+neon");
3) 202004: Insert into line 3353 of file test/Preprocessor/init.c. Remove
the part around AARCH64-NETBSD, and remove line below as well,
// AARCH64:#define __ALIGNOF_MAX_ALIGN_T__ 16
Please simply remove file "CodeGen/aarch64-neon-crypto.c", because it
is
renamed to be CodeGen/neon-crypto.c. I also attached two monolithic patches
for your reference.
To minimize your effort, I already did initial test.
The tests I did cover the followings, and all can pass.
1) LLVM regression test. "make check-all"
2) ARM internal emperor random test
3) Spec2000 test.
Finally, those patches could bring the followings to release 3.4.1,
1) Complete AArch64 NEON feature:
* support all intrinsics as required by ACLE2.0, and enable AArch64 NEON as
default.
* fixed all pattern match issues for AArch64 NEON back-end.
2) Bug fixes:
* Change 64-bit integer type int64_t mapping from "long long" to
"long" and
it potentially affects binary compatibility.
* va_copy run-time behavior failure for AArch64.
* Fix a silent codegen fault for atomic operations (e.g. __sync_...
Intrinsics).
* Fix an assertion failure in A15 SDOptimizer about DPair reg class by
treating DPair as QPR.
* Fix ARM back-end ld/st for v1i64 vector list failure around writeback
mode.
Let me know if you want more info, please! Appreciate your kindly help in
advance!
Thanks,
-Jiangning
2014-03-27 0:10 GMT+08:00 Tom Stellard <tom at stellard.net>:
> Hi,
>
> We are now about halfway between the 3.4 and 3.5 releases, and I would
> like to start preparing for a 3.4.1 release. Here is my proposed release
> schedule:
>
> Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4
> branch.
> April 9 - April 18: Testing Phase
> April 18: 3.4.1 Release
>
> How you can help:
>
> - If you have any bug fixes you think should be included to 3.4.1, send
> me an email with the SVN revision in trunk and also cc the code owner
> and llvm-commits (or cfe-commits if it is a clang patch).
>
> - Start integrating the 3.4 branch into your project or OS distribution
> to and check for any issues.
>
> - Volunteer as a tester for the testing phase.
>
> Thank you,
>
> Tom
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
--
Thanks,
-Jiangning
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/4035034b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: release_3_4_1_llvm.patch.tgz
Type: application/x-gzip
Size: 94936 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/4035034b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: release_3_4_1_clang.patch.tgz
Type: application/x-gzip
Size: 53034 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/4035034b/attachment-0001.bin>
Hi Tom, I would like to nominate the following patches to be backported to 3.4.1 Clang: 1. r204742 - Zinovy Nis <zinovy.nis at gmail.com> - Fix an logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math LLVM: 1. r205067 - Akira Hatanaka <ahatanaka at apple.com> - [x86] Fix printing of register operands with q modifier 2. r203581 - Hans Wennborg <hans at hanshq.net> - X86: Don't generate 64-bit movd after cmpneqsd in 32-bit mode (PR19059) 3. r203146 - Reid Kleckner <reid at kleckner.net> - MS asm: The initial dot in struct access is optional 4. r202774 - Reid Kleckner <reid at kleckner.net> - MC: Fix Intel assembly parser for [global + offset] 5. r201507 - Craig Topper <craig.topper at gmail.com> - Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860 6. r201126 - Robert Khasanov - Changed attributes of all gather intrinsics from IntrReadMem to IntrReadArgMem as they access only memory based on argument. Most patches fix different stable issues on X86 target. Thanks, Robert 2014-03-26 20:10 GMT+04:00 Tom Stellard <tom at stellard.net>:> Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I would > like to start preparing for a 3.4.1 release. Here is my proposed release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 > branch. > April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, send > me an email with the SVN revision in trunk and also cc the code owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase. > > Thank you, > > Tom > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140402/a559ff90/attachment.html>
Hi Tom,
May I ask for one more patch to be back ported to 3.4.1?
*198940 *| kbeyls | Enable -fuse-init-array for all AArch64 ELF targets by
default, not just linux.
Since this is an important bug fix, our customers want it, I'd be extremely
appreciative if it can be dropped into 3.4.1 release as well.
1) You would probably see a patching failure when applying the commit
198940 from trunk to release 3.4.
=============
$ cat lib/Driver/ToolChains.h.rej
--- lib/Driver/ToolChains.h (revision 198939)
+++ lib/Driver/ToolChains.h (revision 198940)
@@ -428,6 +428,9 @@
Generic_ELF(const Driver &D, const llvm::Triple &Triple,
const llvm::opt::ArgList &Args)
: Generic_GCC(D, Triple, Args) {}
+
+ virtual void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
+ llvm::opt::ArgStringList &CC1Args)
const;
};
class LLVM_LIBRARY_VISIBILITY AuroraUX : public Generic_GCC {
=============
and the solution is, inserting those two newly added lines to
class Generic_ELF.
2) But there will be a test failure after this patch, and failure shows
integrated assembler is turned on by default, which shouldn't be acceptable
by this point release.
Actually this patch itself has nothing to do with integrated assembler, and
the root cause is Generic_ELF isn't really be used until this patch is
applied, while the integrated assembler is turned on for Generic_ELF when
creating branch 3.4. Strictly speaking, this is a bug in release 3.4 source
code, but the code isn't really be used, so it can never be exposed by
release 3.4.
Now to fix the "-fuse-init-array" issue addressed by this patch, we
have to
introduce Generic_ELF. On trunk, there are two commits 197024 and 195676 on
trunk removed IsIntegratedAssemblerDefault for Generic_ELF, but we can't
back port them, because those two patches also turned on "integrated
assembler" somewhere else by default for a couple of targets.
Therefore, the solution is we simply remove IsIntegratedAssemblerDefault
implementation for Generic_ELF, and the behavior of Generic_ELF will
follow its parent virtual function, which is defined in ToolChain and
returns false. Refer to the patch below,
diff --git a/lib/Driver/ToolChains.h b/lib/Driver/ToolChains.h
index b54e962..431b2c7 100644
--- a/lib/Driver/ToolChains.h
+++ b/lib/Driver/ToolChains.h
@@ -429,13 +429,6 @@ public:
virtual void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
llvm::opt::ArgStringList &CC1Args)
const;
-
- virtual bool IsIntegratedAssemblerDefault() const {
- // Default integrated assembler to on for x86.
- return (getTriple().getArch() == llvm::Triple::aarch64 ||
- getTriple().getArch() == llvm::Triple::x86 ||
- getTriple().getArch() == llvm::Triple::x86_64);
- }
};
class LLVM_LIBRARY_VISIBILITY AuroraUX : public Generic_GCC {
I tested it and everything looks OK.
Thanks,
-Jiangning
2014-04-01 15:40 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>:
> Hi Tom,
>
> We want the following patches go into release 3.4.1.
>
> Clang:
>
> 196750 [AArch64]Add missing pair intrinsics such as: int32_t
> vminv_s32(int32x2_t a)
> 196834 [AArch64] Remove q and non-q intrinsic definitions from the NEON
> scalar reduce pairwise implementation, using an overloaded definition
> instead.
> 196835 [AArch64] Refactor the NEON scalar reduce pairwise front-end
> codegen to remove unnecessary patterns in tablegen.
> 196836 [AArch64] Refactor the NEON scalar reduce pairwise intrinsics so
> that they use float/double rather than the vector equivalents when
> appropriate.
> 196888 [AArch64 NEON] Support poly128_t and implement relevant intrinsic.
> 196927 [AArch64] Refactor the Neon vector/scalar floating-point convert
> implementation. Specifically, reuse the ARM intrinsics when possible.
> 196931 [AArch64] Refactor the Neon vector/scalar floating-point convert
> intrinsics so that they use float/double rather than the vector equivalents
> when appropriate.
> 196936 [AArch64] Refactor the redundant code in the
> EmitAArch64ScalarBuiltinExpr() function. No functional change intended.
> 196966 [AArch64] Overload NEON signed/unsigned integer convert to
> floating-point LLVM AArch64 intrinsics.
> 196967 [AArch64] Overload NEON signed/unsigned floating-point convert to
> fixed-point and fixed-point convert to floating-point LLVM AArch64
> intrinsics.
> 196968 [AArch64] Refactor the NEON signed/unsigned floating-point convert
> to fixed-point LLVM AArch64 intrinsics to use f32/f64, rather than their
> vector equivalents.
> 196969 [AArch64] Refactor the NEON floating-point absolute difference
> LLVM AArch64 intrinsic to use f32/f64 types, rather than their vector
> equivalents.
> 197069 [AArch64] Refactor the NEON scalar floating-point reciprocal
> estimate, floating-point reciprocal exponent, and floating-point reciprocal
> square root estimate
> 197070 [AArch64] Refactor the NEON scalar floating-point reciprocal step
> and floating-point reciprocal square root step LLVM AArch64 intrinsics to
> 197071 [AArch64] Add NEON scalar floating-point compare LLVM AArch64
> intrinsics that use f32/f64 types, rather than their vector equivalents.
> 197091 [AArch64] Refactor NEON floating-point Max/Min/Maxnm/Minnm across
> vector AArch64 intrinsics to use f32 types, rather than their vector
> equivalents.
> 197112 [AArch64] Fix Incorrect CHECK message [0-31]+ in test case.
> 197403 [AArch64] Fix v1fx patterns for Floating-point Multiply Extend and
> Floating-point Compare to Zero.
> 197898 [AArch64] The compare to zero intrinsics should be implemented by
> 'icmp/fcmp' and 'sext' not 'zext'. Modify the
implementation by replacing
> zext with sext.
> 197994 [AArch64] Add some missing test cases for ACLE intrinsics of
> AArch64 NEON.
> 198195 [AArch64] For AArch64 Neon, simplify scalar dup by lane0 for fp.
> 198741 [AArch64] For AArch64, support builtin neon vector type with
> 'long' as base element type.
> 199866 [AArch64 NEON] Fix a bug about vcles_f32 and vcled_f64.
> 200114 [AArch64] For AArch64 Neon, fix intrinsics implementation using
> nested macros.
> 200470 ARM & AArch64: share the BI__builtin_neon enum defs.
> 200471 ARM & AArch64: fully share NEON implementation of permutation
> intrinsics
> 200472 ARM & AArch64: extend shared NEON implementation to first block.
> 200524 ARM & AArch64: merge another NEON block completely.
> 200525 ARM & AArch64: more instructions into common block
> 200526 ARM & AArch64: move shared vld/vst intrinsics to common
> implementation.
> 200527 ARM & AArch64: another block of miscellaneous NEON sharing.
> 200528 ARM & AArch64: unify the rest of the completely shared NEON
> implementations
> 200707 [AArch64] AArch64: use new non-polymorphic crypto intrinsics This
> was caused by r200708 which enabled the crypto feature for these cores.
> 200708 ARM: implement support for crypto intrinsics in arm_neon.h
> 200769 ARM & AArch64: combine implementation of vcaXYZ intrinsics
> 201112 [AArch64] Fixed vget/vset_lane_f16 implementation
> 201384 [AArch64] Enable AArch64 NEON by default.
> 202004 [AArch64] Change int64_t from 'long long int' to 'long
int' for
> AArch64 target.
>
> LLVM:
>
> 196748 [AArch64]Pattern match failures for truncate store and extend load
> 196749 [AArch64]Add missing pair intrinsics such as: int32_t
> vminv_s32(int32x2_t a)
> 196831 [AArch64] Remove q and non-q intrinsic definitions in the NEON
> scalar reduce pairwise implementation, using an overloaded definition
> instead.
> 196832 [AArch64] Refactor NEON scalar reduce pairwise front-end codegen
> to remove unnecessary patterns in tablegen.
> 196833 [AArch64] Refactor the NEON scalar reduce pairwise intrinsics, so
> that they use float/double rather than the vector equivalents when
> appropriate.
> 196887 [AArch64 NEON] Support poly128_t and implement relevant intrinsic.
> 196889 [AArch64 NEON] Replace fpimm with fpz32 for floating compare with
> zero. This is a small change to be strict. Just want get pattern safer.
> 196926 [AArch64] Refactor the Neon vector/scalar floating-point convert
> implementation. Specifically, reuse the ARM intrinsics when possible.
> 196930 [AArch64] Refactor the Neon vector/scalar floating-point convert
> intrinsics so that they use float/double rather than the vector equivalents
> when appropriate.
> 196962 [AArch64] Overload NEON signed/unsigned integer convert to
> floating-point LLVM AArch64 intrinsics.
> 196963 [AArch64] Overload NEON signed/unsigned floating-point convert to
> fixed-point and fixed-point convert to floating-point LLVM AArch64
> intrinsics.
> 196964 [AArch64] Refactor the NEON signed/unsigned floating-point convert
> to fixed-point LLVM AArch64 intrinsics to use f32/f64, rather than their
> vector equivalents.
> 196965 [AArch64] Refactor the NEON floating-point absolute difference
> LLVM AArch64 intrinsic to use f32/f64 types, rather than their vector
> equivalents.
> 196998 [AArch64 NEON] Get instruction BSL matched to VSELECT.
> 197066 [AArch64] Refactor the NEON scalar floating-point reciprocal
> estimate, floating- point reciprocal exponent, and floating-point
> reciprocal square root estimate
> 197067 [AArch64] Refactor the NEON scalar floating-point reciprocal step
> and floating-point reciprocal square root step LLVM AArch64 intrinsics to
> 197068 [AArch64] Add NEON scalar floating-point compare LLVM AArch64
> intrinsics that use f32/f64 types, rather than their vector equivalents.
> 197090 [AArch64] Refactor NEON floating-point Max/Min/Maxnm/Minnm across
> vector AArch64 intrinsics to use f32 types, rather than their vector
> equivalents.
> 197113 Fix Incorrect CHECK message [0-31]+ in test case. In regular
> expression, [0-31]+ equals to [0-3]+, not the number from
> 197135 [AArch64]Fix the problem that AArch64 backend fails to select
> scalar_to_vector of vector types having more than one element.
> 197159 [AArch64] Removed unnecessary copy patterns with v1fx types.
> 197250 [AArch64] Simplify the Neon Scalar3Same patterns for
> floating-point reciprocal step, floating-point reciprocal square root step,
> floating-point absolute
> 197361 [AArch64]Fix the pattern match failure for v1i8/v1i16/v1i32 types.
> Currently we have such types as legal vector types. The DAG combiner may
> generate some DAG nodes having such types but we don't have patterns to
> match them.
> 197402 [AArch64] Fix v1fx patterns for Floating-point Multiply Extend and
> Floating-point Compare to Zero.
> 197551 [AArch64 NEON]Implment loading vector constant form constant pool.
> 197897 [AArch64]The compare to zero intrinsics should be implemented by
> 'icmp/fcmp' and 'sext' not 'zext'. Modify the test
cases.
> 197928 [AArch64 NEON] Fixed fused multiply negate add/sub patterns
> 197929 [AArch64] Check fmul node single use in fused multiply patterns
> 197966 [AArch64 NEON] Fix a pattern match failure with NEON_VDUP.
> 197967 [AArch64 NEON] Fix a bug when lowering BUILD_VECTOR.
> 197969 [AArch64]Add patterns to match normal shift nodes: shl, sra and
> srl.
> 197993 Add missing pattern matches to support ACLE intrinsics of AArch64
> NEON.
> 198001 [AArch64]Fix a problem that the register order of fmls/fmla by
> element is incorrect.
> 198084 Teach DAGCombiner how to fold a SIGN_EXTEND_INREG of a
> BUILD_VECTOR of ConstantSDNodes (or UNDEFs) into a simple BUILD_VECTOR.
> 198188 [AArch64]Fix the problem that can't select mul of v1i64/v2i64
> types.
> 198190 Fix a bug in DAGcombiner about zero-extend after setcc.
> 198192 [AArch64]Can't select shift left 0 of type v1i64
> 198193 [AArch64]Add code to spill/fill Q register tuples such as
> QPair/QTriple/QQuad.
> 198194 For AArch64 Neon, simplify scalar dup by lane0 for fp.
> 198437 [AArch64][NEON] Added SXTL and SXTL2 instruction aliases
> 198675 [AArch64 NEON] Fixed incorrect immediate used in BIC instruction.
> 198682 [AArch64]Add support to copy D tuples such as DPair/DTriple/DQuad
> and Q tuples such as QPair/QTriple/QQuad. There is no test case for D tuple
> as the original test cases are too large. As the copy of the D tuple is
> similar to the Q tuple, the correctness can be guaranteed.
> 198684 [AArch64]Add support to spill/fill D tuples such as
> DPair/DTriple/DQuad. There is no test cases for D tuple as the original
> test cases are too large. As the spill/fill of the D tuple is similar to
> the Q tuple, the correctness can be guaranteed.
> 198730 Fix a bug about generating undef operand when optimising shuffle
> vector and insert element in instruction combine.
> 198743 [AArch64 NEON] Fix generating incorrect value type of
> NEON_VDUPLANE when lower build_vector if result value type mismatch with
> operand
> 198791 [AArch64][NEON] Added UXTL and UXTL2 instruction aliases
> 198937 Make sure -use-init-array has intended effect on all AArch64 ELF
> targets, not just linux.
> 198941 Silence unused variable warning for non-asserting builds that was
> introduced in r198937.
> 199069 [AArch64 NEON] Add more scenarios to use perm instructions when
> lowering shuffle_vector
> 199070 [AArch64 NEON] Add missing patterns for bitcast from or to v1f64
> 199242 [AArch64] Added vselect patterns with float and double types
> 199296 For AArch64, lowering sext_inreg and generate optimized code by
> using SXTL.
> 199369 For ARM, fix assertuib failures for some ld/st 3/4 instruction
> with wirteback.
> 199461 [AArch64]Fix the problem can't select concat_vectors of two
v1i32
> types. Also fix the problem can't select scalar_to_vector from f32 to
> v2f32/v4f32.
> 199462 [AArch64 NEON] Custom lower conversion between vector integer and
> vector floating point if element bit-width doesn't match.
> 199463 [AArch64]Fix the problem can't select f16_to_f32 and f32_to_f16.
> Also add copy support for FPR16.
> 199485 [AArch64 NEON] Expand vector for UDIV/SDIV/UREM/SREM/FREM as neon
> doesn't support these operations.
> 199621 [AArch64 NEON] Accept both #0.0 and #0 for comparing with floating
> point zero in asm parser.
> 199628 [AArch64 NEON] Fix a bug caused by undef lane when generating VEXT.
> 199631 Revert r199628: "[AArch64 NEON] Fix a bug caused by undef lane
> when generating VEXT."
> 199791 [AArch64 NEON] Try to generate CONCAT_VECTOR when lowering
> BUILD_VECTOR or SHUFFLE_VECTOR.
> 199858 fix some spell mistakes around 'ConcatVector' and
'ShuffleVector'
> in AArch64 backend.
> 199861 [AArch64]Add CHECK for two test cases testing scalar_to_vector
> committed in r199461.
> 199978 [AArch64 NEON] Fix a bug in implementing register copy bwtween
> FPR16.
> 200109 [AArch64 NEON] Fix pattern match failed on FP_ROUND from v1f128 to
> v1f64.
> 200110 [AArch64 NEON] Add test case for vector FP_ROUND.
> 200111 [AArch64 NEON] Add patterns for concat_vector on v2i32.
> 200113 Implement pattern match from v1xx to v1xx for AArch64 Neon.
> 200119 Improve pattern match from v1i8 to v1i32 for AArch64 Neon.
> 200179 Revert r199791.
> 200180 [AArch64 NEON] Try to generate CONCAT_VECTOR when lowering
> BUILD_VECTOR or SHUFFLE_VECTOR.
> 200365 [AArch64 NEON] Lower SELECT_CC with vector operand.
> 200491 [AArch64] Custom lower concat_vector patterns with v4i16, v4i32,
> v8i8, v8i16, v16i8 types.
> 200706 AArch64 & ARM: refactor crypto intrinsics to take scalars
> 200768 ARM & AArch64: merge NEON absolute compare intrinsics
> 201061 [AArch64]Implement the copy of two FPR8 registers by using FMOVss
> of two FPR32 registers in copyPhysReg.
> 201091 [AArch64] Handle aliases of conditional branches without b.pred
> form.
> 201287 [AArch64]Add support for spilling FPR8/FPR16.
> 201298 [AArch64]Fix the problems that can't select mul/add/sub of
> v1i8/v1i16/v1i32 types. As this problems are similar to shl/sra/srl, also
> add patterns for shift nodes.
> 201381 [AArch64]Fix the assertion failure caused by "v1i1 SETCC"
DAG
> node. As v1i1 is illegal, the type legalizer tries to scalarize such node.
> But if the type operands of SETCC is legal, the scalarization algorithm
> will cause an assertion failure.
> 201385 Enable AArch64 NEON by default.
> 201395 [AArch64 NEON] Fix a bug to avoid using floating type as condition
> type in lowering SELECT_CC.
> 201541 Fix a typo about lowering AArch64 va_copy.
> 201793 [AArch64] Add support for TargetTransformInfo Analysis.
> 201841 [AArch64] Add register constraints to avoid generating STLXR and
> STXR with unpredictable behavior.
> 202775 [AArch64]Fix improper diagnostics about offset range of load/store
> instructions.
> 204304 [ARM]Fix an assertion failure in A15SDOptimizer about DPair reg
> class by treating DPair as QPR.
> 204424 [AArch64] Remove .data_region directive from AArch64.
>
> I know the patch list is little bit longer, we have the following reasons,
> 1) Last year, when branch 3.4 was created, actually we didn't really
have
> time to complete all AArch64 neon work. So branch 3.4 is actually at the
> middle stage of aarch64 neon implementation. Now the patches I'm
requesting
> intends to give a complete AArch64 NEON feature.
> 2) There are several critical bug fixes solving compiler crash issue, and
> our end-user really want them to be fixed in new release, and end-user
> can't wait until release 3.5.
> 3) A lot of patches are interleaved and have dependence one another, so
> it's easy to introduce bug if do cherry picking only for some of them.
>
> The patches I listed are in time ordering, so it's easy for you to
apply
> them to branch 3.4. There are only the following failures, but it's
easy to
> be fixed,
> 1) 200708: Only need to manually add line
"Features["crypto"] = true;"
> after line 5924 of file lib/Basic/Targets.cpp
> 2) 201384: Manually add two lines below after line 7135 of
> file lib/Driver/Tools.cpp
> else
> Features.push_back("+neon");
> 3) 202004: Insert into line 3353 of file test/Preprocessor/init.c. Remove
> the part around AARCH64-NETBSD, and remove line below as well,
> // AARCH64:#define __ALIGNOF_MAX_ALIGN_T__ 16
>
> Please simply remove file "CodeGen/aarch64-neon-crypto.c",
because it is
> renamed to be CodeGen/neon-crypto.c. I also attached two monolithic patches
> for your reference.
>
> To minimize your effort, I already did initial test.
> The tests I did cover the followings, and all can pass.
> 1) LLVM regression test. "make check-all"
> 2) ARM internal emperor random test
> 3) Spec2000 test.
>
> Finally, those patches could bring the followings to release 3.4.1,
> 1) Complete AArch64 NEON feature:
> * support all intrinsics as required by ACLE2.0, and enable AArch64 NEON
> as default.
> * fixed all pattern match issues for AArch64 NEON back-end.
> 2) Bug fixes:
> * Change 64-bit integer type int64_t mapping from "long long" to
"long"
> and it potentially affects binary compatibility.
> * va_copy run-time behavior failure for AArch64.
> * Fix a silent codegen fault for atomic operations (e.g. __sync_...
> Intrinsics).
> * Fix an assertion failure in A15 SDOptimizer about DPair reg class by
> treating DPair as QPR.
> * Fix ARM back-end ld/st for v1i64 vector list failure around writeback
> mode.
>
> Let me know if you want more info, please! Appreciate your kindly help in
> advance!
>
> Thanks,
> -Jiangning
>
>
>
>
> 2014-03-27 0:10 GMT+08:00 Tom Stellard <tom at stellard.net>:
>
> Hi,
>>
>> We are now about halfway between the 3.4 and 3.5 releases, and I would
>> like to start preparing for a 3.4.1 release. Here is my proposed
release
>> schedule:
>>
>> Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4
>> branch.
>> April 9 - April 18: Testing Phase
>> April 18: 3.4.1 Release
>>
>> How you can help:
>>
>> - If you have any bug fixes you think should be included to 3.4.1, send
>> me an email with the SVN revision in trunk and also cc the code owner
>> and llvm-commits (or cfe-commits if it is a clang patch).
>>
>> - Start integrating the 3.4 branch into your project or OS distribution
>> to and check for any issues.
>>
>> - Volunteer as a tester for the testing phase.
>>
>> Thank you,
>>
>> Tom
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> --
> Thanks,
> -Jiangning
>
--
Thanks,
-Jiangning
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140403/04ffbc01/attachment.html>
Hi Robert, Can you ping the code owners about these patches. It might be good to write a separate email per code owner and cc the appropriate -commits list. Thanks, Tom On Wed, Apr 02, 2014 at 06:16:44PM +0400, Robert Khasanov wrote:> Hi Tom, > > I would like to nominate the following patches to be backported to 3.4.1 > > Clang: > 1. r204742 - Zinovy Nis <zinovy.nis at gmail.com> - Fix an logic error in the > clang driver preventing crtfastmath.o from linking when -Ofast is used > without -ffast-math > > LLVM: > 1. r205067 - Akira Hatanaka <ahatanaka at apple.com> - [x86] Fix printing of > register operands with q modifier > 2. r203581 - Hans Wennborg <hans at hanshq.net> - X86: Don't generate 64-bit > movd after cmpneqsd in 32-bit mode (PR19059) > 3. r203146 - Reid Kleckner <reid at kleckner.net> - MS asm: The initial dot in > struct access is optional > 4. r202774 - Reid Kleckner <reid at kleckner.net> - MC: Fix Intel assembly > parser for [global + offset] > 5. r201507 - Craig Topper <craig.topper at gmail.com> - Fix diassembler > handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the > base register entirely. Mod=01/10 should treat this as R13 plus > displacment. Fixes PR18860 > 6. r201126 - Robert Khasanov - Changed attributes of all gather intrinsics > from IntrReadMem to IntrReadArgMem as they access only memory based on > argument. > > Most patches fix different stable issues on X86 target. > > Thanks, > Robert > > > > 2014-03-26 20:10 GMT+04:00 Tom Stellard <tom at stellard.net>: > > > Hi, > > > > We are now about halfway between the 3.4 and 3.5 releases, and I would > > like to start preparing for a 3.4.1 release. Here is my proposed release > > schedule: > > > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 > > branch. > > April 9 - April 18: Testing Phase > > April 18: 3.4.1 Release > > > > How you can help: > > > > - If you have any bug fixes you think should be included to 3.4.1, send > > me an email with the SVN revision in trunk and also cc the code owner > > and llvm-commits (or cfe-commits if it is a clang patch). > > > > - Start integrating the 3.4 branch into your project or OS distribution > > to and check for any issues. > > > > - Volunteer as a tester for the testing phase. > > > > Thank you, > > > > Tom > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Tom (and Andy, Owen, Evan, Nadav), I'd like the following commits placed into the 3.4.1 branch. I've attempted to sort this list by code owner: Andrew Trick: r203719 - PR17473 r203725 - This test need the X86 backend, move it to the X86 sub directory. [adjusts the test location from r203719] r202273 - Fix PR18165: LSR must avoid scaling factors that exceed the limit on truncated use. r201104 - [LPM] A terribly simple fix to a terribly complex bug: PR18773. r198863 - Fixed old typo in ScalarEvolution, that caused wrong SCEVs zext operation. Owen Anderson: r200201 - Fix for PR18102. r200202 - Additional fix for 200201: due to dependence on bitwidth test was moved to X86 directory. r200705 - Expand vector bswap in LegalizeVectorOps r205738 - Put a limit on ScheduleDAGSDNodes::ClusterNeighboringLoads to avoid blowing up compile time. Evan Cheng: r200028 - InstCombine: Don't try to use aggregate elements of ConstantExprs. r199351 - BasicAA: We need to check both access sizes when comparing a gep and an r198290 - BasicAA: Fix value equality and phi cycles r198400 - BasicAA: Use reachabilty instead of dominance for checking value equality in phi Nadav Rotem: r199570 - LoopVectorizer: A reduction that has multiple uses of the reduction value is not r199291 - LoopVectorize: Only strip casts from integer types when replacing symbolic Also, please include the following patches in 3.4.1. I am the code owner, and I approve ;) r205630 - [PowerPC] Add a full condition code register to make the "cc" clobber work r204155 - Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0 r203054 - The PPC global base register cannot be r0 r199832 - Fix pr18515. r200288 - Handle spilling the PPC GPRC_NOR0 register class r199763 - Fix pointer info on PPC byval stores r202192 - Account for 128-bit integer operations in PPCCTRLoops r198425 - Fix loop rerolling pass failure with non-consant loop lower bound I apologize the delay; I've not had a chance to refine my list until this morning. Thanks again, Hal ----- Original Message -----> From: "Hal Finkel" <hfinkel at anl.gov> > To: "Tom Stellard" <tom at stellard.net> > Cc: "Ben Pope" <benpope81 at gmail.com>, llvmdev at cs.uiuc.edu, "Erik Verbruggen" <erik.verbruggen at me.com> > Sent: Thursday, March 27, 2014 7:49:36 AM > Subject: Re: [LLVMdev] 3.4.1 Release Plans > > ----- Original Message ----- > > From: "Tom Stellard" <tom at stellard.net> > > To: llvmdev at cs.uiuc.edu > > Cc: "Renato Golin" <renato.golin at linaro.org>, "Sylvestre Ledru" > > <sylvestre at debian.org>, "Sebastian Dreßler" > > <sebastian.dressler at gmail.com>, "Hal Finkel" <hfinkel at anl.gov>, > > "Ben Pope" <benpope81 at gmail.com>, "Arnaud Allard de > > Grandmaison" <arnaud.adegm at gmail.com>, "Erik Verbruggen" > > <erik.verbruggen at me.com> > > Sent: Wednesday, March 26, 2014 11:10:43 AM > > Subject: 3.4.1 Release Plans > > > > Hi, > > > > We are now about halfway between the 3.4 and 3.5 releases, and I > > would > > like to start preparing for a 3.4.1 release. Here is my proposed > > release > > schedule: > > > > Mar 26 - April 9: Identify and backport additional bug fixes to the > > 3.4 branch. > > April 9 - April 18: Testing Phase > > April 18: 3.4.1 Release > > > > How you can help: > > > > - If you have any bug fixes you think should be included to 3.4.1, > > send > > me an email with the SVN revision in trunk and also cc the code > > owner > > and llvm-commits (or cfe-commits if it is a clang patch). > > > > - Start integrating the 3.4 branch into your project or OS > > distribution > > to and check for any issues. > > > > - Volunteer as a tester for the testing phase. > > I'll go through the commit list shortly; also I'll help with testing > on (X86 and PPC64). > > Thanks again for working on this! > > -Hal > > > > > Thank you, > > > > Tom > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On Wed, Mar 26, 2014 at 12:10:43PM -0400, Tom Stellard wrote:> Hi, > > We are now about halfway between the 3.4 and 3.5 releases, and I would > like to start preparing for a 3.4.1 release. Here is my proposed release > schedule: > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch.I'm going to delay the testing phase until Friday, Apr 11. I received a lot more merge requests than I anticipated and a lot of people were busy with the conference this week, so there was not a lot of time for code owners to review patches. However, I would encourage anyone that uses LLVM in ways not covered by the test suite to begin testing the 3.4 branch just to make sure there aren't any major issues. Anyone who requested that I merge a fix into the 3.4 branch should try to verify that it is actually in there. There were a lot of patches and it is possible I over-looked a few. Once the testing phase starts, I plan to only accept patches for bugs that are present in 3.4.1, but not in 3.4.0, so if you have any fixes for bugs in 3.4.0, please get them to by Friday. Thanks, Tom> April 9 - April 18: Testing Phase > April 18: 3.4.1 Release > > How you can help: > > - If you have any bug fixes you think should be included to 3.4.1, send > me an email with the SVN revision in trunk and also cc the code owner > and llvm-commits (or cfe-commits if it is a clang patch). > > - Start integrating the 3.4 branch into your project or OS distribution > to and check for any issues. > > - Volunteer as a tester for the testing phase. > > Thank you, > > Tom > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi, I can help as a tester on Ubuntu x64 -- View this message in context: http://llvm.1065342.n5.nabble.com/3-4-1-Release-Plans-tp67114p67663.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
On Wed, Apr 09, 2014 at 12:14:46PM -0400, Tom Stellard wrote:> On Wed, Mar 26, 2014 at 12:10:43PM -0400, Tom Stellard wrote: > > Hi, > > > > We are now about halfway between the 3.4 and 3.5 releases, and I would > > like to start preparing for a 3.4.1 release. Here is my proposed release > > schedule: > > > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. > > I'm going to delay the testing phase until Friday, Apr 11. I received a > lot more merge requests than I anticipated and a lot of people were busy > with the conference this week, so there was not a lot of time for code > owners to review patches. >I have just sent out emails to code owners for all the outstanding patches that need approval to be merged. If you have nominated a patch that has not been merged and you were not cc'ed on an email to one of the code owners with a subject containing 'OK to merge ...', please ping me to make sure your patch hasn't fallen through the cracks. Thanks, Tom> However, I would encourage anyone that uses LLVM in ways not covered by > the test suite to begin testing the 3.4 branch just to make sure there > aren't any major issues. > > Anyone who requested that I merge a fix into the 3.4 branch should try > to verify that it is actually in there. There were a lot of patches and > it is possible I over-looked a few. > > Once the testing phase starts, I plan to only accept patches for bugs > that are present in 3.4.1, but not in 3.4.0, so if you have any fixes > for bugs in 3.4.0, please get them to by Friday. > > Thanks, > Tom > > > > April 9 - April 18: Testing Phase > > April 18: 3.4.1 Release > > > > How you can help: > > > > - If you have any bug fixes you think should be included to 3.4.1, send > > me an email with the SVN revision in trunk and also cc the code owner > > and llvm-commits (or cfe-commits if it is a clang patch). > > > > - Start integrating the 3.4 branch into your project or OS distribution > > to and check for any issues. > > > > - Volunteer as a tester for the testing phase. > > > > Thank you, > > > > Tom > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Tom, 2014-04-09 18:14 GMT+02:00 Tom Stellard <tom at stellard.net>:> On Wed, Mar 26, 2014 at 12:10:43PM -0400, Tom Stellard wrote: > > Hi, > > > > We are now about halfway between the 3.4 and 3.5 releases, and I would > > like to start preparing for a 3.4.1 release. Here is my proposed release > > schedule: > > > > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 > branch. > > Once the testing phase starts, I plan to only accept patches for bugs > that are present in 3.4.1, but not in 3.4.0, so if you have any fixes > for bugs in 3.4.0, please get them to by Friday.Got a quick question regarding the testing process: can we use the test script which was provided by Bill for testing 3.4? This was very convenient to use... Cheers, Sebastian> Thanks, > Tom > > > > April 9 - April 18: Testing Phase > > April 18: 3.4.1 Release > > > > How you can help: > > > > - If you have any bug fixes you think should be included to 3.4.1, send > > me an email with the SVN revision in trunk and also cc the code owner > > and llvm-commits (or cfe-commits if it is a clang patch). > > > > - Start integrating the 3.4 branch into your project or OS distribution > > to and check for any issues. > > > > - Volunteer as a tester for the testing phase. > > > > Thank you, > > > > Tom > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140411/f788767c/attachment.html>