[llvm] r179957 - SimplifyCFG: If convert single conditional stores

[Arnold Schwaighofer]

On Apr 20, 2013, at 10:19 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:

> On 4/20/13 6:36 PM, Arnold Schwaighofer wrote:
>> On Apr 20, 2013, at 8:30 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>> 
>>> On 4/20/13 6:04 PM, Arnold Schwaighofer wrote:
>>>> On Apr 20, 2013, at 7:54 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>>>> 
>>>>> It tail dup the load, which dosen't necessarily simplify the CFG.
>>>>> I'm from CFG simplification perspective.
>>>>> 
>>>> It does not perform select/if conversation of the store - hence my patch.
>>> I guess the "it" here refers to the GVN. The GVN actually perform some PRE here. I don't like PRE
>>> is taking place in the early stage (actually in my local hack to GVN, I'm actually trying to disable all
>>> PRE  in the early invocation of GVN). It only complicate the CFG because it insert some code in
>>> empty block (by edge-splitting) during code motion phase
>> By "it" I meant the LLVM opt pass pipeline. GVN gets rid of a redundant load. (It sees a store on one side of the if and a store one the other so no need to load again just use a phi of the two store values - no need to split an edge either)
> 
> I take back the lame motivating example. I sort of mix what we are having and what I'm trying to do.
> To avoid unnecessary confusion, I don't like to discuss here.
>> 
>>> Actually, PRE dose not always win here, what if the branch is balanced and the ISA dosen't have
>>> instruction for conditional store? We will suffer from branch misprediction here.
>>> 
>>> What I'm talking about here is about the better motivation to get rid of the guarding condition of
>>> the store --- blindly strip if off vs with some motivations.
>>> 
>> My motivation are branch mispredictions. This is why we are so bad on hmmer. We (clang) already gets rid of those loads.
> How do you know you reduce the misprediction at this moment? The branch is not completely removed, and
> you don't know the underlying architecture support for conditional move etc.

My transform replaces the conditional branch by a conditional move (select at llvm ir level). The branch is completely removed

a[i] = X
… // here we might have an may-aliasing load otherwise other transformations would already remove the redundant store.
if (cond) a[i] = Y;

=>

a[i] = X
…
tmp = (cond) ? Y : X;
a[i] = tmp;

Any architecture we support supports some form of conditional move as far as I am aware. We can conditionalize this transform on a TTI flag if need to be.
> 
> On the other hand, in theory, without knowing the branching outcome, downstream PRE/GVN can remove
> the partial redundant store by reverting back to you have done early…

LLVM's GVN does not undo selects as far as I am aware off if this is what you mean.


> 
> 
> 
>> 
>>> I'm sorry I were not clear in my previous mails. Seems like I should not write email during week-end:-)
>>> 
>>> 
>>>> But the loads are already eliminated so I can't use them to motivate my patch - that is all I am saying.
> But it is pretty late.
>>> I believe you change takes place early than GVN?
>> Yes, but the motivation are not the load because we already get rid of them.
> 
>