Yep. Please backport r203146 and r202774, they should be fairly isolated.
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
I approve!
-Andy
I approve.
—Owen
Yes, if x86 owners are fine with it.
Hi Nadav,
Would you approve Akira’s r205067 patch to be backported to 3.4.1?
Thanks,
Robert
I just merged these patches.
-Tom
Hi Hal,
I was able to merge all the fixes approved by Owen, except for r200705.
The test case for that commit doesn't pass on the 3.4 branch. I've attached
the output from llc and FileCheck. Could you send me an updated patch
with a test case that work on 3.4?
Thanks,
Tom
bswap-vector.out (2.07 KB)
Hi Reid,
Would you approve your patches r203146 and r202774 to be backported to
3.4.1? They fix stability issues in x86 asm.
Hi Robert,
I was able to merge r203146, but it used a c++11 feature:
std::string::back() which I replaced with
std::string::at(std::string::size() - 1).
r202774 was not merged, because it is dependent on r198584 which adds the
X86AsmParser::is32BitMode() function. I don't think we would need to
backport all of r198584, maybe just the function and the Mode32Bit
SubtargetFeature. Could you take a look and let me know what you want
to do?
Thanks,
Tom
Hi Hal,
Nadav Rotem:
r199570 - LoopVectorizer: A reduction that has multiple uses of the reduction value is notr199291 - LoopVectorize: Only strip casts from integer types when replacing symbolic
This commit changes the functions
replaceSymbolicStrideSCEV() and InnerLoopVectorizer::addStrideCheck(),
which were both added in r198950, so when I apply it to 3.4 nothing
changes. If the bug fixed by this commit is present in 3.4, you may
need to come up with a different patch to fix it.
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
The test case for this fails on the 3.4 branch, so I was not able to
merge it. The problem is that cmpld instructions are generated instead of
cmpd. Can you take a look?
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 PPCCTRLoopsr198425 - Fix loop rerolling pass failure with non-consant loop lower bound
The rest of the patches approved by you and Nadav have been merged.
-Tom
From: "Tom Stellard" <tom@stellard.net>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Andrew Trick" <atrick@apple.com>, "Owen Anderson" <owen@apple.com>, "Evan Cheng" <evan.cheng@apple.com>, "nadav"
<nadav@apple.com>, "Ben Pope" <benpope81@gmail.com>, llvmdev@cs.uiuc.edu, "Erik Verbruggen" <erik.verbruggen@me.com>
Sent: Tuesday, April 8, 2014 7:28:01 PM
Subject: Re: [LLVMdev] 3.4.1 Release PlansHi Hal,
> 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 symbolicThis commit changes the functions
replaceSymbolicStrideSCEV() and
InnerLoopVectorizer::addStrideCheck(),
which were both added in r198950, so when I apply it to 3.4 nothing
changes. If the bug fixed by this commit is present in 3.4, you may
need to come up with a different patch to fix it.
I'm sorry, you're right. There is nothing to fix there in 3.4.
> 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 workThe test case for this fails on the 3.4 branch, so I was not able to
merge it. The problem is that cmpld instructions are generated
instead of
cmpd. Can you take a look?
Will do shortly (but I'll cc llvm-commits instead of llvmdev).
-Hal
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
I approve taking r200028.
Thanks,
Evan
From: "Evan Cheng" <evan.cheng@apple.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Tom Stellard" <tom@stellard.net>, "Andrew Trick" <atrick@apple.com>, "Owen Anderson" <owen@apple.com>, "nadav"
<nadav@apple.com>, "Ben Pope" <benpope81@gmail.com>, "LLVM Dev" <llvmdev@cs.uiuc.edu>, "Erik Verbruggen"
<erik.verbruggen@me.com>
Sent: Wednesday, April 9, 2014 12:23:38 PM
Subject: Re: [LLVMdev] 3.4.1 Release PlansI approve taking r200028.
Thanks! Do you not want to take the BasicAA fixes, or do you just want more time to look at them? [It looks like Tom is giving us all until Friday]. I would like to pull them into 3.4.1 because they fix miscompiles.
-Hal
Hi Hans,
Would you approve your patch r203581 to be backported to 3.4.1? It fixes
stability issue on x86.
Yes, I approve.
Cheers,
Hans
Hi,
I can help as a tester on Ubuntu x64
Hi Tom,
llvm_202774_34.diff (3.32 KB)
> 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
Hi Tom,
I approve taking r200028.
This patch has been merged.
-Tom