[LLVMdev] Casting between address spaces and address space semantics

[Matthijs Kooijman]

Hi Mon Ping,

I've again attached a patch, wich lets LLVM know about about the relations
between different address spaces. Instead of cramming this info in with
TargetData (with all kinds of unwanted side effects, especially for the IR), I
opted to create a new pass, TargetAddrspaces, which holds this information.
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 bitcasts from a subset to a superset address
space. It gets at the address space information by requiring the
TargetAddrspaces analysis, which will give it the default implementation in
all current tools.

So, this requires a minimal amount of changes, the current code won't know the
difference, and in our custom frontend we provide another implementation of
TargetAddrspaces and things work very well.

There are a number of issues still, though. I'm not 100% sure that using an
Analysis pass for this is correct, but currently only analysis passes can be
grouped (though I have the suspicion that this is mainly a question of naming,
really).

Additionally, the "Writing an LLVM Pass" document states: "There must be
exactly one default implementation available at all times for an Analysis
Group to be used. Only default implementation can derive from ImmutablePass."

I'm not completely sure why there cannot be other implementations that
derive from ImmutablePass. In this case, I want to have any implementation of
TargetAddrspaces also derive from ImmutablePass, because it makes sense. In
practice, this works as well, our custom implementeation as well as the
default implementation derive from ImmutablePass and everything compiles and
runs fine. Is this perhaps an outdated statement?

Mon Ping suggests using address space information for alias analysis as well,
which seems to make sense. In effect this is a form of type-based alias
analysis, but different address spaces don't preclude pointers from being
equal. A problem here is that pointers in disjoint address spaces would be
marked as not aliasing, but when the default relation is disjoint this is not
so conservative. This might require an extra option "Unknown", which can be
used as the default instead of "Disjoint". For Unknown, any pass can do the
conservative thing.

Lastly, I'm still not so sure if InstCombine is the right place for this
simplification. This needs some more thought, but currently it is a problem
that instcombine does not process BitCastConstantExprs. I might end up writing
a seperate pass for just this.


So again, suggestions welcome.

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addrspaces.diff
Type: text/x-diff
Size: 9792 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080807/b63e2bde/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080807/b63e2bde/attachment.sig>