llvm dev - Jun 2015 - [LLVMdev] Any known-reliable numbering scheme for basic blocks?

Hi all,

Does anyone know of a good solution to the following?  I'm trying to find a
good way to stably associate distinct ID numbers with different BB in a
module.  As long as the module's IR hasn't changed in any way
whatsoever,
I'd like to be guaranteed to always generate the same ID <--> BB
mapping.
Or if the mapping is ambiguous, because two or more mappings between BB's
and ID's are indistinguishable (isomorphic?), I'd like to be sure I at
least can reliably re-obtain some mapping in that equivalence class.

This seems related to a debate / bug-report
<https://llvm.org/bugs/show_bug.cgi?id=16043> regarding the arbitrary
nature of (pseudo?) labels in LLVM assembly.  E.g.,*"; label:3"*.

It also looks like *llvm-diff* does something similar to what I want in its
*FunctionDifferenceEngine* class.  But I think *llvm-diff* allows for the
two IR's to differ, and uses approximate matching.  I don't need any
graceful degradation when the IR has changed, but I need exact matching
when the IR hasn't changed.

In the worst-case scenario, I could make a sweep through all of the
module's BB's and just tag each BB with a distinct serial number in its
metadata.  But I'd like to avoid this if possible, partly because I'd
like
there to be a chance of the BB <--> ID mapping remaining valid if I run
Clang.

Thanks, Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/26ee118c/attachment.html>

Hi Christian,

I’m guessing you would want a mechanism similar to what we use for PGO (which I
do not know how it works :)).

+ Justin who works on PGO.

Cheers,
-Quentin
> On Jun 24, 2015, at 6:05 PM, Christian Convey <christian.convey at
gmail.com> wrote:
> 
> Hi all,
> 
> Does anyone know of a good solution to the following?  I'm trying to
find a good way to stably associate distinct ID numbers with different BB in a
module.  As long as the module's IR hasn't changed in any way
whatsoever, I'd like to be guaranteed to always generate the same ID
<--> BB mapping.  Or if the mapping is ambiguous, because two or more
mappings between BB's and ID's are indistinguishable (isomorphic?),
I'd like to be sure I at least can reliably re-obtain some mapping in that
equivalence class.
> 
> This seems related to a debate / bug-report
<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D16043&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=VyhVlhie270AiA60rcYOf3Vw5xKKZFKAgr5GK6hPXu0&s=Kv0Xo7jx0HJ8mumCx_vW368qV5lXoVdMAygrhChMMFU&e=>
regarding the arbitrary nature of (pseudo?) labels in LLVM assembly. 
E.g.,"; label:3".
> 
> It also looks like llvm-diff does something similar to what I want in its
FunctionDifferenceEngine class.  But I think llvm-diff allows for the two
IR's to differ, and uses approximate matching.  I don't need any
graceful degradation when the IR has changed, but I need exact matching when the
IR hasn't changed.
> 
> In the worst-case scenario, I could make a sweep through all of the
module's BB's and just tag each BB with a distinct serial number in its
metadata.  But I'd like to avoid this if possible, partly because I'd
like there to be a chance of the BB <--> ID mapping remaining valid if I
run Clang.
> 
> Thanks, Christian
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/76e86139/attachment.html>

Hi Quentin, thanks for the tip.  I'll have a look.  Much appreciated.

- C

On Wed, Jul 1, 2015 at 2:39 PM, Quentin Colombet <qcolombet at apple.com>
wrote:
> Hi Christian,
>
> I’m guessing you would want a mechanism similar to what we use for PGO
> (which I do not know how it works :)).
>
> + Justin who works on PGO.
>
> Cheers,
> -Quentin
>
> On Jun 24, 2015, at 6:05 PM, Christian Convey <christian.convey at
gmail.com>
> wrote:
>
> Hi all,
>
> Does anyone know of a good solution to the following?  I'm trying to
find
> a good way to stably associate distinct ID numbers with different BB in a
> module.  As long as the module's IR hasn't changed in any way
whatsoever,
> I'd like to be guaranteed to always generate the same ID <--> BB
mapping.
> Or if the mapping is ambiguous, because two or more mappings between
BB's
> and ID's are indistinguishable (isomorphic?), I'd like to be sure I
at
> least can reliably re-obtain some mapping in that equivalence class.
>
> This seems related to a debate / bug-report
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D16043&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=VyhVlhie270AiA60rcYOf3Vw5xKKZFKAgr5GK6hPXu0&s=Kv0Xo7jx0HJ8mumCx_vW368qV5lXoVdMAygrhChMMFU&e=>
> regarding the arbitrary nature of (pseudo?) labels in LLVM assembly. 
E.g.,*";
> label:3"*.
>
> It also looks like *llvm-diff* does something similar to what I want in
> its *FunctionDifferenceEngine* class.  But I think *llvm-diff* allows for
> the two IR's to differ, and uses approximate matching.  I don't
need any
> graceful degradation when the IR has changed, but I need exact matching
> when the IR hasn't changed.
>
> In the worst-case scenario, I could make a sweep through all of the
> module's BB's and just tag each BB with a distinct serial number in
its
> metadata.  But I'd like to avoid this if possible, partly because
I'd like
> there to be a chance of the BB <--> ID mapping remaining valid if I
run
> Clang.
>
> Thanks, Christian
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/8002e3ff/attachment.html>