Displaying 5 results from an estimated 5 matches for "alias_set".
2009 Mar 24
0
[LLVMdev] C++ type erasure in llvm-g++
...built up as a structure instead of an array. I'd
guess it shouldn't be more than 100 lines. Harder to do would be to
transform the virtual dispatch code. It is exposed as just raw add/
subtract, fetch and then indirect call. Seems like part of the
solution may be to propagate the ALIAS_SET information from the type
system down for llvm to reason with. It should be more complete and
accurate than the information llvm has, though, maybe only marginally
so. The saving grace would be the code is heavily stylized and you're
getting it before the optimizer swizzles it on you....
2009 Mar 24
3
[LLVMdev] C++ type erasure in llvm-g++
I'm curious about the type erasure that goes on when llvm-g++ compiles
C++ code. Is this a consequence of it just being the easiest way to do
things based on the design of gcc and how LLVM is plugged into it?
Can someone more familiar with the llvm-gcc infrastructure comment on
the difficulty of generating more strongly typed virtual function tables
rather than just having them all be
2009 Mar 24
2
[LLVMdev] C++ type erasure in llvm-g++
...ure instead of an array. I'd
> guess it shouldn't be more than 100 lines. Harder to do would be to
> transform the virtual dispatch code. It is exposed as just raw add/
> subtract, fetch and then indirect call. Seems like part of the
> solution may be to propagate the ALIAS_SET information from the type
> system down for llvm to reason with. It should be more complete and
> accurate than the information llvm has, though, maybe only marginally
> so. The saving grace would be the code is heavily stylized and you're
> getting it before the optimizer...
2007 Apr 30
0
[LLVMdev] Boostrap Failure -- Expected Differences?
...file format elf32-i386
> -stage2/alias.o
> +alias.o: file format elf32-i386
> +alias.o
> architecture: i386, flags 0x00000011:
> HAS_RELOC, HAS_SYMS
> start address 0x00000000
> @@ -23,7 +23,7 @@
> 00000000 l d .bss 00000000
> 00000010 l O .bss 00000004 alias_sets
> 000003c7 l O .rodata 0000003a .str
> -000005fb l O .rodata 00000014 __FUNCTION__.20030
> +000005fb l O .rodata 00000014 __FUNCTION__.19945
> 00000000 l d .rodata 00000000
> 000003f0 l F .text 0000005e gt_ggc_ma_reg_known_value
> 00000014 l O .bss 000...
2007 Apr 27
2
[LLVMdev] Boostrap Failure -- Expected Differences?
The saga continues.
I've been tracking the interface changes and merging them with
the refactoring work I'm doing. I got as far as building stage3
of llvm-gcc but the object files from stage2 and stage3 differ:
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
(Are the above two ok?)
The list below is clearly bad. I think it's every object file in
the