Displaying 4 results from an estimated 4 matches for "pr309".
Did you mean:
pr300
2004 Apr 04
2
[LLVMdev] Two important changes to the getelementptr instruction
...rlier releases, as
usual, will work fine with the newer version. In particular, we will
always support .ll files that use ubyte indexes for structure types, as
the parser auto-upgrades them to uint indexes.
This change fixes the following bugs:
http://llvm.cs.uiuc.edu/PR82
http://llvm.cs.uiuc.edu/PR309
It also results in cleaner and simpler LLVM code, allowing many integer
casts that were present for array indexes to go away. Though the encoding
of getelementptr instructions is slightly less efficient than before
(because we have to store what type the various sequential type operands
are), the...
2004 Apr 04
0
[LLVMdev] Two important changes to the getelementptr instruction
...work fine with the newer version. In particular, we will
> always support .ll files that use ubyte indexes for structure types, as
> the parser auto-upgrades them to uint indexes.
>
> This change fixes the following bugs:
> http://llvm.cs.uiuc.edu/PR82
> http://llvm.cs.uiuc.edu/PR309
>
> It also results in cleaner and simpler LLVM code, allowing many integer
> casts that were present for array indexes to go away. Though the encoding
> of getelementptr instructions is slightly less efficient than before
> (because we have to store what type the various sequentia...
2004 Apr 05
1
[LLVMdev] Two important changes to the getelementptr instruction
...sion. In particular, we will
> > always support .ll files that use ubyte indexes for structure types, as
> > the parser auto-upgrades them to uint indexes.
> >
> > This change fixes the following bugs:
> > http://llvm.cs.uiuc.edu/PR82
> > http://llvm.cs.uiuc.edu/PR309
> >
> > It also results in cleaner and simpler LLVM code, allowing many integer
> > casts that were present for array indexes to go away. Though the encoding
> > of getelementptr instructions is slightly less efficient than before
> > (because we have to store what ty...
2004 Apr 21
4
[LLVMdev] x86 cogen quality
Hi, I have a question about x86 code quality.
I have run a few benchmarks and compared the
running time of executables created by LLVM to
executables created by gcc.
It appears that code generated by LLVM is x1.5 - x3
times slower than code generated by gcc, for the x86
For some of the benchmarks the linear scan regalloc
works. When it does, results are in the x1.0 - 1.5
range. Unfortunately,