[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Question on not sharing trees (tree_node_can_be_shared)
From:       Richard Biener via Gcc <gcc () gcc ! gnu ! org>
Date:       2022-03-21 13:39:00
Message-ID: CAFiYyc13NGJRhHYxNrvCGhgUug+7A529UWswCJd7cqUeBOycvw () mail ! gmail ! com
[Download RAW message or body]

On Mon, Mar 21, 2022 at 11:56 AM Erick Ochoa <eochoa@gcc.gnu.org> wrote:
>
> Hi,
>
> I am interested in annotating INTEGER_CSTs. I have added a field to typed=
_trees and set the value in some cases. However, INTEGER_CSTs can be shared=
 and copied across the function and even copied to other functions. I don't=
 want all INTEGER_CSTs with the same value to be shared as now they have an=
 annotation which may make them somewhat unique. My question is, is there a=
 way to disable sharing of INTEGER_CSTs?

Not really.  There's a special "kind" of INTEGER_CSTs not shared,
those with TREE_OVERFLOW set.

But I'd advise against un-sharing of INTEGER_CSTs, can't you annotate
sth higher level up?

>
> I have tried modifying tree_node_can_be_shared to return false when the a=
rgument is an INTEGER_CST. However, the verifier then fails stating that th=
ere was an incorrect sharing of tree nodes. My intuition tells me that this=
 means that some pass assumes that INTEGER_CSTs can be shared and therefore=
 the information gets copied. However, during the verifier this gets caught=
 and returns an error. Is this correct? How would one go around and disable=
 sharing INTEGER_CSTs?
>
> Is there a tree comparison for INTEGER_CSTs that I can set such that if a=
n INTEGER_CST has my field set then it registers as a different INTEGER_CST=
 even if they have the same constant value?
>
> Thanks!
[prev in list] [next in list] [prev in thread] [next in thread]