[llvm-dev] adding 2 new functions to the AliasAnalysis interface

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] adding 2 new functions to the AliasAnalysis interface

Robin Eklind via llvm-dev
Hi,
RFC

Im adding 2 new functions to the AliasAnalysis interface:

1) ModRefSameBufferCheck:

this function will receive 2 memoryLocation as parameters, and returns
true if the parameters are modifying or refering the same buffer or
same memory block, false otherwise.

2) getAddressesDistance:

the function will recieve 2 memoryLocation, if they are mod/ref-ing
the same buffer/memory block, the function will return the distance
between those locations at the memory. None otherwise
(Optional<int64_t>)


interface change:
https://reviews.llvm.org/D46864


those 2 function can be impelemented easly in AlisAnalysis and can help
alot of users, a usage example is for detecting bank conflicts (using the
distance between memoryLoc and the number and size of the banks you can
know if you have a conflict).
implementation and usage example (with code duplication for a first
implementation, lets discuss the idea first):
https://reviews.llvm.org/D46928

I saw one bad implemntation for detecting bank conflicts in Hexagon
open-source, but it wont realy work for most of examples, they only check
if the registers are equal.. in my implamentation I check the real distance
between locations...


thanks,
Atheel Massalha
Compiler Engineer


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

Re: [llvm-dev] adding 2 new functions to the AliasAnalysis interface

Robin Eklind via llvm-dev
On 6/20/2018 2:31 AM, Atheel Massalha via llvm-dev wrote:
Hi,
RFC

Im adding 2 new functions to the AliasAnalysis interface:

1) ModRefSameBufferCheck:

this function will receive 2 memoryLocation as parameters, and returns
true if the parameters are modifying or refering the same buffer or
same memory block, false otherwise.

I'm not completely sure what "same buffer" means; is it just that given MemoryLocations with addresses A and B, an offset N exists such that gep(A,N) is mustalias with B?  What happens if alias can't prove whether the two locations point to the "same buffer"?

Is that actually the property you care about?  DependenceAnalysis would probably be more appropriate if you're trying to analyze cross-iteration dependencies in loops.

Could you implement this by just calling alias() with the sizes set to UnknownSize?

2) getAddressesDistance:

the function will recieve 2 memoryLocation, if they are mod/ref-ing
the same buffer/memory block, the function will return the distance
between those locations at the memory. None otherwise
(Optional<int64_t>)

If I'm following correctly, given two values A and B, if a small constant offset N is known such that A+N==B, N is returned; if the distance is unknown or not a constant, None is returned.  Not sure why the API takes memoryLocations, instead of just two Value*.  Not sure this really belongs in AliasAnalysis.

-Eli
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

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

Re: [llvm-dev] adding 2 new functions to the AliasAnalysis interface

Robin Eklind via llvm-dev
thanks for your reply,
1) what is Im trying to analyze is the 2 memory instructions are using the same "Bank" of memory, Bank is a column in the physical memory rows of a memory block, for that I need to known if 2 instructions are using same block (usually, 2 different arrays are mapped to different blocks, but for [int* a=b+1], 'a' and 'b' will be in the same block, do oyu mean that "unkownSize" will always return "mayAlias"/"noAlias" for same/different blocks? sounds good idea, I will try it.

2) true. because it needs the size and the pointerInfo

another use fir this 2 interfaces is for "merging" load instructions registers, as for today, LLVM generates different register names for ld instructions with same base pointer but different offset, this can be optimized using the knowledge of the distance between them.
*any suggestions for improving this?

sorry for the late response, 

thanks,
Atheel

On 20 June 2018 at 22:02, Friedman, Eli <[hidden email]> wrote:
On 6/20/2018 2:31 AM, Atheel Massalha via llvm-dev wrote:
Hi,
RFC

Im adding 2 new functions to the AliasAnalysis interface:

1) ModRefSameBufferCheck:

this function will receive 2 memoryLocation as parameters, and returns
true if the parameters are modifying or refering the same buffer or
same memory block, false otherwise.

I'm not completely sure what "same buffer" means; is it just that given MemoryLocations with addresses A and B, an offset N exists such that gep(A,N) is mustalias with B?  What happens if alias can't prove whether the two locations point to the "same buffer"?

Is that actually the property you care about?  DependenceAnalysis would probably be more appropriate if you're trying to analyze cross-iteration dependencies in loops.

Could you implement this by just calling alias() with the sizes set to UnknownSize?

2) getAddressesDistance:

the function will recieve 2 memoryLocation, if they are mod/ref-ing
the same buffer/memory block, the function will return the distance
between those locations at the memory. None otherwise
(Optional<int64_t>)

If I'm following correctly, given two values A and B, if a small constant offset N is known such that A+N==B, N is returned; if the distance is unknown or not a constant, None is returned.  Not sure why the API takes memoryLocations, instead of just two Value*.  Not sure this really belongs in AliasAnalysis.

-Eli
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


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