search for: uicast

...intptr > intptr to ptr > intptr to signed int > signed int to intptr > intptr to unsigned int > unsigned int to intptr > > Does that seem reasonable? > > Sure. Another option is to do away with sext/trunc/etc. and just > have two cast operations for ints: sicast and uicast. sicast > converts any int size to any other (with sign extension if the > destination type is bigger), and uicast is the same but with zero > extension. sext/zext/trunc are very nice for the optimizer, we should keep them. It means that the optimizer doesn't have to check th...

...> ptr to intptr > intptr to int > intptr to signed int > signed int to intptr > intptr to unsigned int > unsigned int to intptr > > Does that seem reasonable? > Sure. Another option is to do away with sext/trunc/etc. and just have two cast operations for ints: sicast and uicast. sicast converts any int size to any other (with sign extension if the destination type is bigger), and uicast is the same but with zero extension. That leaves just ptrtoint and inttoptr - which incidentally have the same semantics as sicast and uicast. > > - Converting to FP types: Eithe...

...;> signed int to intptr >> intptr to unsigned int >> unsigned int to intptr >> >> Does that seem reasonable? >> >> >> Sure. Another option is to do away with sext/trunc/etc. and just have >> two cast operations for ints: sicast and uicast. sicast converts any >> int size to any other (with sign extension if the destination type is >> bigger), and uicast is the same but with zero extension. > > sext/zext/trunc are very nice for the optimizer, we should keep them. > It means that the optimizer doesn't have...

On Nov 12, 2009, at 11:29 AM, Talin wrote: > > Well, as far as intp goes (or iptr if you prefer - the naming > convention in LLVM is i<size>) How about "intptr". > here's what I would expect: > General rule #1: If an instruction accepts both i32 and i64, then it > should accept iptr as well. If it only accepts i32, then it can > continue to only