Displaying 3 results from an estimated 3 matches for "reg102".
Did you mean:
reg1024
2002 Sep 28
2
[LLVMdev] Directory and library rename:
By request, I've renamed lib/CodeGen/PreSelection to lib/CodeGen/PreOpts
(admittedly this was my choice :-), and the corresponding archive from
preselect to preopt. If you see linker errors saying preselect.o is not
found, this is the reason. This shouldn't happen if you update your entire
tree at once.
--Vikram
2002 Sep 28
0
[LLVMdev] the getelementptr noop problem
...expect
int ** x = <some array>;
int ** y = x[0];
to work unless we cast x[0] as an int **, and not the int * it would
otherwise return.
moreover, if this were something that we could really count on acting as a
noop, then we could have
%reg101 = getelementptr %mystruct * %reg100, uint 0
%reg102 = getelementptr %mystruct * %reg101, uint 0
... and so on, and not make a difference. which to me seems the same as
%regn = getelementptr %mystruct * %reg100, uint 0, uint 0, ...
which *ought to be* indexing deep into some array.
so -- what exactly does the first indexing uint 0 do? is it sa...
2002 Sep 29
1
[LLVMdev] the getelementptr noop problem
...t would
> otherwise return.
Remember that it is returning a POINTER to the indexed value... so it's
&x[0]...
> moreover, if this were something that we could really count on acting as a
> noop, then we could have
>
> %reg101 = getelementptr %mystruct * %reg100, uint 0
> %reg102 = getelementptr %mystruct * %reg101, uint 0
> ... and so on, and not make a difference. which to me seems the same as
That's true...
> %regn = getelementptr %mystruct * %reg100, uint 0, uint 0, ...
> which *ought to be* indexing deep into some array.
Yes, unfortunately, getelemen...