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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
Hi All,

  Skim through Hexagon backend, I notice there is HexagonCommonGEP.cpp which seems
try to do something on `getelementptr` LLVM instruction. But what exactly it want to do?
Anyone knows?

  Thanks.

Regards,
chenwj

--
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
On 6/14/2017 7:44 AM, 陳韋任 via llvm-dev wrote:
>
>    Skim through Hexagon backend, I notice there is HexagonCommonGEP.cpp
> which seems
> try to do something on `getelementptr` LLVM instruction. But what
> exactly it want to do?
> Anyone knows?

Each getelementptr is a chain that starts with a pointer, followed by an
index, which together produce a new pointer. That new pointer coupled
with the next index on the operand list produced yet another pointer,
and so on. Each GEP can actually be broken up into shorter GEPs, where
the next one starts at the address generated by the previous one. It is
fairly common to have GEP instructions that in their entirety generate
different pointers, but where the initial few pointers are identical.
The core task of HexagonCommonGEP is to isolate the initial identical
addresses into their own GEP instructions. It then does several other
things, like finding the best placement of the commoned GEPs (with
respect to loop invariance), etc.

-Krzysztof

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
Sounds like you break a single getelementptr into a few smaller ones, then do CSE-like optimization?

2017-06-14 21:11 GMT+08:00 Krzysztof Parzyszek via llvm-dev <[hidden email]>:
On 6/14/2017 7:44 AM, 陳韋任 via llvm-dev wrote:

   Skim through Hexagon backend, I notice there is HexagonCommonGEP.cpp which seems
try to do something on `getelementptr` LLVM instruction. But what exactly it want to do?
Anyone knows?

Each getelementptr is a chain that starts with a pointer, followed by an index, which together produce a new pointer. That new pointer coupled with the next index on the operand list produced yet another pointer, and so on. Each GEP can actually be broken up into shorter GEPs, where the next one starts at the address generated by the previous one. It is fairly common to have GEP instructions that in their entirety generate different pointers, but where the initial few pointers are identical. The core task of HexagonCommonGEP is to isolate the initial identical addresses into their own GEP instructions. It then does several other things, like finding the best placement of the commoned GEPs (with respect to loop invariance), etc.

-Krzysztof

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
On 6/14/2017 8:16 AM, 陳韋任 wrote:
> Sounds like you break a single getelementptr into a few smaller ones,
> then do CSE-like optimization?

Something like that.

-Krzysztof

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
I only see Hexagon has such optimization, is there any reason that Hexagon need this?
No existing optimization does similar thing?

Thanks,

Regards,
chenwj


2017-06-14 21:51 GMT+08:00 Krzysztof Parzyszek <[hidden email]>:
On 6/14/2017 8:16 AM, 陳韋任 wrote:
Sounds like you break a single getelementptr into a few smaller ones, then do CSE-like optimization?

Something like that.


-Krzysztof

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



--
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel via llvm-dev
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
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel 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 <[hidden email]> 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


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hal Finkel 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 <[hidden email]> 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 <[hidden email]> 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



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Loading...