3 ms·

> tend not to be translatable into usable metadata LLVM tbaa honestly seems so straight-forward and not language-specific... actually you're the one who taught

> tend not to be translatable into usable metadata LLVM tbaa honestly seems so straight-forward and not language-specific... actually you're the one who taught me this! I mean how many ways can you describe one-to-many aliasing relations?

DannyBee 10y ago
>> tend not to be translatable into usable metadata >LLVM tbaa honestly seems so straight-forward and not language-specific" It also represents a very non-complex aliasing relationship :) IE type dags. I could also point out it's horrendously broken and about to be redesigned (but to be fair, this was just 'unions were a hack in tbaa, nobody realized how much of a hack until they started really digging') https://bugs.llvm.org/show_bug.cgi?id=32056 https://bugs.llvm.org/show_bug.cgi?id=32056 The result will just look like gcc's. But this is also subject to fairly simple rules, and those rules fail to let you optimize in a lot of cases. IE the language itself says what the rules are. I can't use the type system to say "circle types never alias square types" if it's not in the language rules instead, if i do this: struct circle { int radius; int x; int y; }; struct square { int size; int x; int y; } There is actually no way in C, translated to llvm, to say pointers to these things these do not alias (i don't remember all the versions of the common initial sequence rules off the top of my head to know whether it's possible at all. Assume for our purposes it's not) in fact, in llvm, it's worse. It has a "type system" that is useless (literally), and in that type system, you can't even distinguish or prove that a given access is to a different field (because it allows negative offsets). We have no metadata that specifies it (remember the struct tbaa info is about types of fields, not access paths in generals) So TBAA will not help with that. Thus, in the above case, a pointer to any field will may-alias every other field. (This is what llvm will do, other compilers are much better) The best you get in C is restrict, which is pretty weak. This is the use case a type system helps, where you want to be able to assert things that you can't easily express. But then you have to translate that assertion, again, into something the compiler understands. Compiler type systems and language type systems are pretty much never identical. This is also info that requires translation from high level to low level :(
- flamedoge 10y ago
  I do wish compilers were smart enough to differentiate between circle.int* and int*. If I was a C programmer, I would expect my compiler to be able to tell this difference :(.

DannyBee 10y ago

>> tend not to be translatable into usable metadata >LLVM tbaa honestly seems so straight-forward and not language-specific" It also represents a very non-complex aliasing relationship :) IE type dags. I could also point out it's horrendously broken and about to be redesigned (but to be fair, this was just 'unions were a hack in tbaa, nobody realized how much of a hack until they started really digging') https://bugs.llvm.org/show_bug.cgi?id=32056 https://bugs.llvm.org/show_bug.cgi?id=32056 The result will just look like gcc's. But this is also subject to fairly simple rules, and those rules fail to let you optimize in a lot of cases. IE the language itself says what the rules are. I can't use the type system to say "circle types never alias square types" if it's not in the language rules instead, if i do this: struct circle { int radius; int x; int y; }; struct square { int size; int x; int y; } There is actually no way in C, translated to llvm, to say pointers to these things these do not alias (i don't remember all the versions of the common initial sequence rules off the top of my head to know whether it's possible at all. Assume for our purposes it's not) in fact, in llvm, it's worse. It has a "type system" that is useless (literally), and in that type system, you can't even distinguish or prove that a given access is to a different field (because it allows negative offsets). We have no metadata that specifies it (remember the struct tbaa info is about types of fields, not access paths in generals) So TBAA will not help with that. Thus, in the above case, a pointer to any field will may-alias every other field. (This is what llvm will do, other compilers are much better) The best you get in C is restrict, which is pretty weak. This is the use case a type system helps, where you want to be able to assert things that you can't easily express. But then you have to translate that assertion, again, into something the compiler understands. Compiler type systems and language type systems are pretty much never identical. This is also info that requires translation from high level to low level :(

flamedoge 10y ago
I do wish compilers were smart enough to differentiate between circle.int* and int*. If I was a C programmer, I would expect my compiler to be able to tell this difference :(.