similar to: [LLVMdev] Casting between address spaces and address space semantics

On Thu, Jul 17, 2008 at 5:08 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Now, we are using a function which reads a value from one of these memories > and does some processing. Since we want to execute this function for multiple > memories, we make it accept a pointer in the generic address space (ie, no > address space attribute): > > void do_stuff(char*

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

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

Hi Gordon, > TargetData is a concrete class, part of the middle-end. It describes > parts of the the target's ABI. It allows target-independent passes to > do things like decide whether x[1] and ((char *) x)[4] alias. This is > possible without actually linking with the code generator for the > relevant target. TargetData can be encoded in the LLVM IR, e.g. target

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

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

On Jul 21, 2008, at 11:58 PM, Matthijs Kooijman wrote: >> >> You probably want to somehow extend TargetData to encode the address >> space descriptions, including pointer sizes and address space >> relationships. > Hmm, you have an excellent point there, pointer sizes could indeed > easily have > different sizes in different address spaces... That would make

Hi Matthijs, Sorry for not responding earlier. I have a few comments. On Aug 7, 2008, at 7:41 AM, Matthijs Kooijman wrote: > 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

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

On 2008-07-21, at 14:42, Matthijs Kooijman wrote: > Hi Mon Ping, > >> As you also mentioned, I don't like that we pass a reference to >> TargetData with the AddrspacesDescriptor and that we have a static >> default implementation store in the class. It is unclear to me if >> this is the right class for it as not as it describes the structure >> and

Hi Mon Ping, > As you also mentioned, I don't like that we pass a reference to > TargetData with the AddrspacesDescriptor and that we have a static > default implementation store in the class. It is unclear to me if > this is the right class for it as not as it describes the structure > and alignment while address spaces seems distinct from that. I feel > that

Hi Chris, > >> You probably want to somehow extend TargetData to encode the address > >> space descriptions, including pointer sizes and address space > >> relationships. > > Hmm, you have an excellent point there, pointer sizes could indeed easily > > have different sizes in different address spaces... That would make > > TargetData indeed a logical

Hi all, > If I read the standard correctly, the properties of these address spaces can > be fully captured by defining the relationship between every pair of address > spaces (disjoint, identical, subset/superset). > > I think it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address

On Jul 22, 2008, at 1:36 AM, Matthijs Kooijman wrote: >> Yep, I think it makes sense for TargetData to have info about the >> size/ >> alignment of a pointer in each addr space. That is also easy to >> encode. > Which is an added bonus, but the original subject under discussion > was the > relations between each address space (equivalent, disjoint, subset/

Hello, Using the technique suggested here ( https://stat.ethz.ch/pipermail/r-devel/2007-September/047028.html), we can update a matrix in place (see example 1 below), with huge time and memory savings. Is it possible to tweak example 2 to update in place also? The only difference is that the matrix is held within a new environment. Thanks, Simon # example 1 - fast and doesn't

Hi Matthijs, Thanks for giving some code so we can discuss this in more concrete detail. In terms of the information we need, I think you have it right. We just need a description of how the different address spaces relate and I don't see much of an issue with how you implemented to InstructionCombining. As you also mentioned, I don't like that we pass a reference to

Hi All, I've been fiddling around with a DenseMap to store cached copies of some result. In short, I'm doing the following: It = Map.find(Key) if (It != Map.end() && It->second != Unknown) Return It->second; // do_stuff return Map[Key] = Result; However, I this requires two lookups in the hash table, which is not so nice. Currently, there is no way to write this down so

Hi all, I've taken preglows ARM versions of qmf_synth and iir_mem16 from rockboxes speex codec, and tweaked them a bit further for some more speed. I attach them here so you can review and take on any changes you want. Please let me know if you have questions etc. Thanks, Robin -- Robin Watts, Email: <mailto:Robin.Watts@wss.co.uk> Warm Silence Software, WWW:

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*