[llvm-dev] What is HexagonCommonGEP.cpp for?

[Ryan Taylor via llvm-dev]

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>