search for: alldisjointaddrspaces

...t, then. Any comments on this? Chris, would this be acceptable? > I want to treat my next point with some delicacy as I don't want to start a > religious war. I just want to get clarification from the community on the > use of multiple inheritance for the case of Phases like > AllDisjointAddrspaces. From what I can gather, the use of multiple > inheritance is to separate the interface (TargetAddrSpace) to access data > from the interface of the phase (ImmutablePhase). In this case, will we > ever create a concrete class from TargetAddrSpace that doesn't also derive > fro...

...and other people feel it is cleaner with a separate pass, I'm fine with it. I want to treat my next point with some delicacy as I don't want to start a religious war. I just want to get clarification from the community on the use of multiple inheritance for the case of Phases like AllDisjointAddrspaces. From what I can gather, the use of multiple inheritance is to separate the interface (TargetAddrSpace) to access data from the interface of the phase (ImmutablePhase). In this case, will we ever create a concrete class from TargetAddrSpace that doesn't also derive from ImmutablePass?...

...ormation. Just like TargetData, this can be added to the passmanager by the tool running the passes. Unlike TargetData, however, I wanted to be able to subclass TargetAddrspaces to change the behaviour. To make this possible, I made TargetAddrspaces an analysis group, with a default implementation AllDisjointAddrspaces (which, as the name suggests, returns Disjoint for all combinations). Having a default implementations is useful, so tools are not required to add a TargetAddrspaces pass to a passmanager. The last part of this patch is an addition to InstCombine to make use of this information: It removes any bit...

Hi Mon Ping, > I don't have a problem having another class, TargetAddrSpace, to store this > information. However, I don't think it make sense being a standalone pass. > Address spaces seems to part of the TargetData and it seems more natural > to ask the TargetData to return the TargetAddrSpace object (similar to > struct layout) to describe the relationships

...dded to the passmanager by the > tool running > the passes. > > Unlike TargetData, however, I wanted to be able to subclass > TargetAddrspaces > to change the behaviour. To make this possible, I made > TargetAddrspaces an > analysis group, with a default implementation AllDisjointAddrspaces > (which, as > the name suggests, returns Disjoint for all combinations). Having a > default > implementations is useful, so tools are not required to add a > TargetAddrspaces > pass to a passmanager. > I don't have a problem having another class, TargetAddrSpace, to...

Hi Matthijs, > >>> Specifically, I would like instcombining to be able to use this >>> info to >>> remove useless bitcasts. Also, this information is useful for >>> clang to >>> know when inserting an implicit cast makes sense and when it >>> would be an >>> error. >> Clang should just reject implicit casts in *any*

Hi all, I've been a tad busy in the last few weeks, but I don't think this issue is settled yet. > > the relations between each address space (equivalent, disjoint, subset/ > > superset). > > Any thoughts on that? Should they also belong in TargetData? > Only if absolutely required, see below. Is there any other place they would fit in better? What piece of below