llvm dev - Jun 2017 - What is HexagonCommonGEP.cpp for?

Krzystof,

  Is this partly due to hardware loops not being common? I'm curious, we do
something very similar for similar reasons.



On Wed, Jun 14, 2017 at 10:23 AM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 6/14/2017 9:05 AM, 陳韋任 wrote:
>
>> I only see Hexagon has such optimization, is there any reason that
>> Hexagon need this?
>>
>
> This question is backwards. Since it was written in the first place, there
> obviously was a reason for it. It was originally written for Hexagon and so
> it remains as a Hexagon-only optimization. It could become a
> target-independent optimization, but so far nothing has been done to
> evaluate the impact of it for other targets.
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170614/897e4c42/attachment.html>

On 6/14/2017 9:27 AM, Ryan Taylor wrote:
> 
>    Is this partly due to hardware loops not being common? I'm curious, 
> we do something very similar for similar reasons.
The original motivation was to avoid recomputation these parts of the 
address that were shared between different GEPs. Hexagon has a very 
large number of complex instructions, and these instructions could span 
various parts of the address calculation. This makes it prohibitively 
difficult to extract the common parts after instruction selection.

It also places the common GEPs as far out in the loop nest as possible 
(in the outermost region with respect to invariance). In addition to 
that, it will put a GEP before each load and store that is expected to 
be fully folded into an addressing mode of the load/store. As of now, it 
only does that for indexed modes (i.e. base reg + immediate offset), but 
Hexagon has a bunch more that could be exploited as well.

We don't do anything specifically related to hardware loops until much 
later in the codegen. What situations do you have in your target?

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

We support hardware loops.

Our solution for this is two fold, we do both IR level and MI level passes.
The IR does most of the loop recognition and similar GEP transformations
and we utilize intrinsics to 'outline' the loop. We use the MI to
construct
the instruction given the intrinsics and set register classes, etc...

For us there just isn't a reasonable way to get all the info we need in the
backend and it's best to use the abstracted mem computation (GEP).

On Wed, Jun 14, 2017 at 10:44 AM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> On 6/14/2017 9:27 AM, Ryan Taylor wrote:
>
>>
>>    Is this partly due to hardware loops not being common? I'm
curious, we
>> do something very similar for similar reasons.
>>
>
> The original motivation was to avoid recomputation these parts of the
> address that were shared between different GEPs. Hexagon has a very large
> number of complex instructions, and these instructions could span various
> parts of the address calculation. This makes it prohibitively difficult to
> extract the common parts after instruction selection.
>
> It also places the common GEPs as far out in the loop nest as possible (in
> the outermost region with respect to invariance). In addition to that, it
> will put a GEP before each load and store that is expected to be fully
> folded into an addressing mode of the load/store. As of now, it only does
> that for indexed modes (i.e. base reg + immediate offset), but Hexagon has
> a bunch more that could be exploited as well.
>
> We don't do anything specifically related to hardware loops until much
> later in the codegen. What situations do you have in your target?
>
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170614/bfe658e2/attachment-0001.html>