search for: targetaddrspace

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...

...> 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 mad...

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 rel...

Hi Matthijs, On Aug 11, 2008, at 4:09 AM, Matthijs Kooijman wrote: > >> 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 >>...

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 Mon Ping, > If I remember correctly, I was also not fond of passing another > TargetAddrSpace reference to the TargetData object. I was hoping that we > could encode the information as a target description string like we do for > ABI information. I just don't want to end up with too many objects that > describe the machine. One can argue that we shouldn't pollute the...

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