[llvm-dev] [RFC] Aggreate load/store, proposed plan

[Mehdi Amini via llvm-dev]

Hi,

To be sure, because the RFC below is not detailed and assume everyone knows about all the emails from 10 months ago, is there more to do than what is proposed in http://reviews.llvm.org/D9766 ?

So basically the proposal is that *InstCombine* turns aggregate load/store into a load/store using an integer of equivalent size and insert the correct bitcast before/after, right? 

Example is:

  %0 = tail call i8* @allocmemory(i64 32)
  %1 = bitcast i8* %0 to %B*
  store %B { %B__vtbl* @B__vtblZ, i32 42 }, %B* %1, align 8

into:

store i128 or (i128 zext (i64 ptrtoint (%B__vtbl* @B__vtblZ to i64) to i128), i128 774763251095801167872), i128* %1, align 8

Where the aggregate is:

%B__vtbl = type { i8*, i32 (%B*)* }
@B__vtblZ = constant %B__vtbl { i8* null, i32 (%B*)* @B.foo }


Thanks,

— 
Mehdi


> On Aug 19, 2015, at 5:02 PM, deadal nix via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> It is pretty clear people need this. Let's get this moving.
> 
> I'll try to sum up the point that have been made and I'll try to address them carefully.
> 
> 1/ There is no good solution for large aggregates.
> That is true. However, I don't think this is a reason to not address smaller aggregates, as they appear to be needed. Realistically, the proportion of aggregates that are very large is small, and there is no expectation that such a thing would map nicely to the hardware anyway (the hardware won't have enough registers to load it all anyway). I do think this is reasonable to expect a reasonable handling of relatively small aggregates like fat pointers while accepting that larges ones will be inefficient.
> 
> This limitation is not unique to the current discussion, as SROA suffer from the same limitation.
> It is possible to disable to transformation for aggregates that are too large if this is too big of a concern. It should maybe also be done for SROA.
> 
> 2/ Slicing the aggregate break the semantic of atomic/volatile.
> That is true. It means slicing the aggregate should not be done for atomic/volatile. It doesn't mean this should not be done for regular ones as it is reasonable to handle atomic/volatile differently. After all, they have different semantic.
> 
> 3/ Not slicing can create scalar that aren't supported by the target. This is undesirable.
> Indeed. But as always, the important question is compared to what ?
> 
> The hardware has no notion of aggregate, so an aggregate or a large scalar ends up both requiring legalization. Doing the transformation is still beneficial :
>  - Some aggregates will generate valid scalars. For such aggregate, this is 100% win.
>  - For aggregate that won't, the situation is still better as various optimization passes will be able to handle the load in a sensible manner.
>  - The transformation never make the situation worse than it is to begin with.
> 
> On previous discussion, Hal Finkel seemed to think that the scalar solution is preferable to the slicing one.
> 
> Is that a fair assessment of the situation ? Considering all of this, I think the right path forward is :
>  - Go for the scalar solution in the general case.
>  - If that is a problem, the slicing approach can be used for non atomic/volatile.
>  - If necessary, disable the transformation for very large aggregates (and consider doing so for SROA as well).
> 
> Do we have a plan ?
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=KkqzAZMcLUlWa3Uwmbr4DQqJdYQAzN_pFY3M8dzVdZ8&s=SFb1jraizjgechN0Pq3738tzBZyK8dZRqIU8Zfi_Qns&e=