Displaying 7 results from an estimated 7 matches for "predecrement".
2017 Mar 22
3
arg_iterator missing inc/dec operators
Reid,
After your recent redefinition of arg_iterator, it's missing
increment/decrement operators (which people typically expect to be defined
for iterators). So some external code relying on this is broken. If it's
not intentional, would be nice to have it fixed.
Specific code that I is broken looks like this:
llvm::Function f;
foo(--f->arg_end()); // passing the last argument to the
2017 Mar 22
2
arg_iterator missing inc/dec operators
> The predecrement / decrement operators *do* exist on this iterator:
> https://github.com/llvm-mirror/llvm/blob/master/include/
> llvm/ADT/ilist_iterator.h#L153
>
> Maybe you meant:
>
> llvm::Function *f;
> foo(&*--f->arg_end());
>
> ?
>
Correct, I mean exactly this. Though...
2014 Oct 23
2
[LLVMdev] Question regarding getElementPtr/Addressing modes in backend
...c.edu>" <llvmdev at cs.uiuc.edu>
> Sent: Thursday, October 23, 2014 8:31:35 AM
> Subject: Re: [LLVMdev] Question regarding getElementPtr/Addressing modes in backend
>
> Many CPU instruction sets have "autoincrement" / "postincrement"
> (pop) / "predecrement" (push) instructions that dereference a
> pointer register and also alter it by the size of the load or store.
>
>
> The PowerPC has "load byte/short/word with update" instructions that
> add an arbitrary positive or negative literal offset (unrelated to
> the loa...
2014 Oct 23
2
[LLVMdev] Question regarding getElementPtr/Addressing modes in backend
Hi Steve,
Thanks for the tip regarding MIOperandInfo, I didn't think of that part of
the tablegen description.
Sadly, I did actually mean: r1 = *(i0 += m0).
So increment i0 by m0. Read memory the memory location "pointed" to by i0.
Store in r1. Sadly I am not too familiar with compiler terminology, so I
don't know if there is a proper term for such a load.
On Thu, Oct 23,
2015 Jan 31
3
[LLVMdev] Encoding instructions with inconsistent formats
...nt -- take a look at this
table of variants of LD, along with their machine code representation:
# load 8 bits from pointer register X into general purpose Rd
ld Rd, X `1001 000d dddd 1100`
ld Rd, X+ `1001 000d dddd 1101` (load with postincrement)
ld Rd, -X `1001 000d dddd 1110` (load with predecrement)
ld Rd, Y `1000 000d dddd 1000`
ld Rd, Y+ `1001 000d dddd 1001`
ld Rd, -Y `1001 000d dddd 1010`
ld Rd, Z `1000 000d dddd 0000`
ld Rd, Z+ `1001 000d dddd 0001`
ld Rd, -Z `1001 000d dddd 0010`
^
|
Note this one inconsistent bit
One way to...
2002 Nov 13
2
survreg (survival) reports erroneous results for left-censored data (PR#2287)
Full_Name: Tim Cohn
Version: 1.6.1
OS: Macintosh OS X
Submission from: (NULL) (130.11.34.250)
The Mac version of survreg does not handle left-censored data correctly (at
least the results are not what I get doing it other ways, and they are not the
same as I get running R 1.6.1 in Windows 98se; the Windows 98 results are
correct). On the windows version of R 1.6.1.
>
2019 Mar 11
3
IsDead, IsKill
Thanks.
I saw the header comments but it wasn’t clear to me what the difference between those concepts is?
My slightly vague understanding is IsDef means that the register specified by this operand is set by the machine instruction. So I understand that to mean the MO will override that register?
Also things like early clobber, perhaps there is another document that clarifies some of these