search for: targetaddrspaces

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

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

...breaks this, unless we also make a string representation of the address spaces that we can put in a module. I think that having a seperate class is somewhat cleaner, since it also makes sure that this info is only made available to the passes that actually use it. > BTW, there is a comment in TargetAddrspaces.h that indicate the default is > that all address spaces are equivalent. I assume you meant disjoint here. Uh, yeah :-) >> 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 >> addre...

...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. >> >> For the case of a GetElementPointer, we are replacing a bitcast to a >> pointer, getelem with a getelem bitcast. The assumption is the >> latter >> bitcas...

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

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