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

[Ryan Taylor via llvm-dev]

Also, we have several similar instructions in different parts of the
architecture (ie data computation vs memory computation, which have some
overlapping register sets) and we take a similar approach to solve this
issue. We break down GEPs in the IR and use intrinsics to help define the
mapping (for example, IR add node might go to exu add or memory addressing,
but the pattern is the same). In the DAG we mark these nodes as index
operations and then use code in tablegen to map to either, for example, a
data add or memory add.

On Wed, Jun 14, 2017 at 11:22 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

> 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/af0d91a2/attachment.html>