I've been reading this list for a while, but this is the first thing I have any real
expertise on, so I have to comment :-) (I haven't done any compiler work, but I've done lots of simd coding). On aliasing: I guess there are a small number of 'use cases' for converting one type of pointer to another in the kind of code which you would need SIMD for: a) when you are extracting some heterogenous values from a stream of bytes. BitC must be able to deal with this already, because OS's have to do it as well (eg, a process has given me some memory, and I want to treat it as a 'struct sockaddr'.) b) When what you really have is a stream of bytes, but you use a 'uint64_t *' to express the fact that it is 64 bit aligned. As noted, bitc can express alignment separately to type, so it is ahead here. c) conversions between the underlying atomic types, such as signed to unsigned etc. IMO, this would be covered if bitc allows the intrinsics to be overloaded, so you are allowed to define overloaded versions which do the conversion for you. then you don't need to keep two pointers to the same data with different types. (It is not obvious from my skimming how much overloading by type bitc allows?) d) Conversions due to the simd intrinsics wanting to operate on chunks of 4 , 8 etc atomic types. IMO, this is only a problem in C because of its weak array typing. if int[4] is a first class type, and the language supports some mechanism to extract an int[4] from and int[512] by some kind of slicing operation, then you can just make the arguments to your intrinsics something like 'const int[4]'. (The language spec doesn't mention a slicing operation, but I guess you don't need one if the compiler is smart enough to recognise that's what you are trying to do). Both c) and d) lead me to the conclusion that you want to reduce aliassing where possible by keeping only one pointer to a given piece of data, and doing any conversions on values rather than pointers. On the whole, I think that if you have a function taking two pointer arguments, you don't want the compiler to assume that they can be aliased, at least by default. That removes lots of optimisations it could otherwise do. However, maybe this is the opposite to what you want in a systems programming language, where you value predictability over speed. (If that is the case, maybe my previous paragraph is wrong). The only cases where I can think of where you *have* to alias things are on memory constrained systems where you need to overwrite your input with your output. In that case you can move reads of the input before writes to the output, but not later. It's not clear that you could express that to a compiler :-) Alex _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
