Optimize load from aggregate stores

[Owen Anderson]

On Jun 12, 2014, at 9:02 AM, Philip Reames <listmail at philipreames.com> wrote:

> On 06/12/2014 12:28 AM, Owen Anderson wrote:
>> 
>> On Jun 11, 2014, at 11:29 PM, deadal nix <deadalnix at gmail.com> wrote:
>> 
>>> It is gonna improve the situation quite a lot for all frontend that use aggregate loads (arguably, that is a bad practice, but that no reason to stab people in the back when they do it anyway).
>> 
>> I’m not sure I agree with that statement.  If we don’t think they should be used, not optimizing them is a good way to discourage that.  More generally, I’m concerned about how we will ever get good test coverage of this code path, since we don’t have any extant front ends that hit it.
> I'm joining this discussion late, but a) why are aggregate loads bad practice?  Loading something like a small struct from memory with a single load seems reasonable.

They are not well supported through the code generator, and introducing them would add a lot of complexity.  There are better solutions already in use.  The only encouraged use case for first class structs is as multiple return values.

> b) There are frontends that are not in tree.  The fact that Deadal submitted the patch is a good hint that *someone* cares.

That’s not the same as saying that they *should* care.  The project regularly makes policy and/or technical decisions that favor good practices over bad.  As an extreme example, we don’t even try to promote non-entry-block allocas to virtual registers.  Totally possible, but we have collectively decided that the extra complexity is not worth it when we can just tell frontend authors to adopt best practice and put their allocas in the entry block.  This example is firmly in line with that.

Moreover, we generally prefer not to add functionality that is not exercised in open code.  A single regression test is not good enough.  That verifies that one case works, but we’ll never find the cases that don’t work, or that interact improperly with other optimizations, because we have no way of actually testing it live.

—Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140612/85a00feb/attachment.html>