release_33 branch: proposing r185594, r185615, r185616 and r185617

[Dimitry Andric]

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:
>> Hi,
>> 
>> 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
>>  nodes.
>> 
> 
> 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:
>   https://groups.google.com/forum/#!msg/llvm-dev/NLxx_8SIaHI/5aNecjnpeXEJ


Would it be considered breaking the ABI to make the members private?  Or
is anything that changes the class layout out of the question?

-Dimitry