release_33 branch: proposing r185594, r185615, r185616 and r185617
dimitry at andric.com
Sat Jul 20 13:31:50 PDT 2013
On Jul 19, 2013, at 16:39, Tom Stellard <tom at stellard.net> wrote:
> On Mon, Jul 08, 2013 at 09:55:47PM +0200, Dimitry Andric wrote:
>> For the 3.3 release branch, I would like to propose merging r185594, r185615, r185616 and r185617:
>> r185594 from llvm trunk (by Jakob Stoklund Olesen):
>> Add MachineBasicBlock::addLiveIn().
>> This function adds a live-in physical register to an MBB and ensures
>> that it is copied to a virtual register immediately.
> This patch adds a public function which I think will break the ABI, and
> it was decided that stable releases shouldn't break the ABI.
This is reasonably easy to work around (though a little ugly).
>> r185617 from llvm trunk (by Jakob Stoklund Olesen):
>> Simplify landing pad lowering.
>> Stop using the ISD::EXCEPTIONADDR and ISD::EHSELECTION when lowering
>> landing pad arguments. These nodes were previously legalized into
>> CopyFromReg nodes, but that never worked properly because the
>> CopyFromReg node weren't guaranteed to be scheduled at the top of the
>> basic block.
>> This meant the exception pointer and selector registers could be
>> clobbered before being copied to a virtual register.
>> This patch copies the two physical registers to virtual registers at
>> the beginning of the basic block, and lowers the landingpad instruction
>> directly to two CopyFromReg nodes reading the *virtual* registers. This
>> is safe because virtual registers don't get clobbered.
>> A future patch will remove the ISD::EXCEPTIONADDR and ISD::EHSELECTION
> This patch adds two new public members which I also think will break the
> ABI. I don't think I can accept r185594 and r185617 unless you can either:
> 1. Rework them in a way that doesn't break the ABI.
> 2. Revive the discussion about ABI compatibility of stable release and
> get a general consensus that breaking the ABI is OK. The original
> discussion is here:
Would it be considered breaking the ABI to make the members private? Or
is anything that changes the class layout out of the question?
More information about the llvm-commits