Displaying 15 results from an estimated 15 matches for "extendedintegerresults".
2009 Mar 31
4
[LLVMdev] promotion of return value.
> Did you see this Ali?
> http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
Would you mind adding it to SVN? Would make it easier
to comment on. In particular, it would be nice to add
examples for X86 (caller extends. High bits undefined
in the callee) and PPC (callee extends).
And I still don't understand why in
short y();
int z() {
return ((int)y() <<...
2009 Mar 31
0
[LLVMdev] promotion of return value.
On Mar 31, 2009, at 11:46 AM, Alireza.Moshtaghi at microchip.com wrote:
> Any thoughts on this?
> I would like to get it right before jumping into the nuts and bolts
> of it….
Did you see this Ali?
http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090331/0eff1a30/attachment.html>
2012 Oct 23
2
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
...re i8 zeroext @foo()
>
> the caller knows that the top bits of the return are 0. There was some
> discussion about just using the range metadata, but that is not
> available for arguments/returns at the moment.
Chris wrote some notes about this:
http://www.nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
The plan seems sensible to me, but was blocked by not having a good
way of attaching the information to parameters and return values.
Hopefully Bill's attribute work means it is now possible.
Ciao, Duncan.
2009 Mar 31
3
[LLVMdev] promotion of return value.
Any thoughts on this?
I would like to get it right before jumping into the nuts and bolts of
it....
Thanks
________________________________
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Alireza.Moshtaghi at microchip.com
Sent: Thursday, March 12, 2009 10:39 AM
To: llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev] promotion of return value.
2012 Oct 24
2
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
Hi Hal,
>> Chris wrote some notes about this:
>> http://www.nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
>> The plan seems sensible to me, but was blocked by not having a good
>> way of attaching the information to parameters and return values.
>> Hopefully Bill's attribute work means it is now possible.
>
> Indeed. Are you proposing that Ulrich hold off on the current...
2009 Apr 01
0
[LLVMdev] promotion of return value.
On Mar 31, 2009, at 12:04 PM, Rafael Espindola wrote:
>> Did you see this Ali?
>> http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
>
> Would you mind adding it to SVN? Would make it easier
> to comment on. In particular, it would be nice to add
> examples for X86 (caller extends. High bits undefined
> in the callee) and PPC (callee extends).
Sure, I checked it in here:
llvm/docs/ExtendedIntegerResults.txt...
2012 Oct 23
0
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
...caller knows that the top bits of the return are 0. There was
> > some
> > discussion about just using the range metadata, but that is not
> > available for arguments/returns at the moment.
>
> Chris wrote some notes about this:
> http://www.nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
> The plan seems sensible to me, but was blocked by not having a good
> way of attaching the information to parameters and return values.
> Hopefully Bill's attribute work means it is now possible.
Indeed. Are you proposing that Ulrich hold off on the current fix in favor of the n...
2012 Oct 31
0
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
Duncan Sands <duncan.sands at gmail.com> wrote on 24.10.2012 08:20:07:
> Hal Finkel <hfinkel at anl.gov> wrote:
> >> Chris wrote some notes about this:
> >> http://www.nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
> >> The plan seems sensible to me, but was blocked by not having a good
> >> way of attaching the information to parameters and return values.
> >> Hopefully Bill's attribute work means it is now possible.
> >
> > Indeed. Are you proposing that Ulrich...
2009 Mar 31
0
[LLVMdev] promotion of return value.
Rafael Espindola wrote:
>> Did you see this Ali?
>> http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
>
> Would you mind adding it to SVN? Would make it easier
> to comment on. In particular, it would be nice to add
> examples for X86 (caller extends. High bits undefined
> in the callee) and PPC (callee extends).
>
> And I still don't understand why in
>
> shor...
2012 Mar 24
0
[LLVMdev] [RFC] Using i8 for boolean return types and arguments.
..., !tbaa !0, !range !3
%tobool = icmp ne i8 %0, 0
ret i1 %tobool
}
Which I think is the perfect IL if we are going to return an i1.
Unfortunately, this still codegens to
cmpb $0, (%rdi)
setne %al
ret
One way to fix this is to implement
http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt. The
attached patch does it for boolean types only. The result is that the
IL (after the optimizer simplify it) becomes
define i8 @_Z1fPb(i8* nocapture %x) nounwind readonly optsize {
entry:
%0 = load i8* %x, align 1, !tbaa !0, !range !3
ret i8 %0
}
and the assembly is
movb (%rdi), %al...
2012 Oct 22
0
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
On 22 October 2012 14:53, Chandler Carruth <chandlerc at google.com> wrote:
> So, I'm not really sure if this is the right approach. I'd like some
> folks from the LLVM side of things to chime in.
>
> In general, I'm not certain we want to continue growing our dependence
> on the signext and zeroext attributes on return types, or whether we
> want to do the
2013 Feb 25
1
[LLVMdev] PR 12207: sign extension of parameters and return values on x86-64
Hi,
I recently spent a bit of time looking into
http://llvm.org/bugs/show_bug.cgi?id=12207. After talking to a bunch
of different projects (including libffi and python, which is where I
actually ran into issues), I found out that it seems that LLVM is in
the wrong here after all. I noted such on the issue, but haven't
gotten a response.
There's a recent relevant thread in
2012 Feb 23
0
[LLVMdev] x86-64 sign extension for parameters and return values
On Wed, Feb 8, 2012 at 6:49 PM, Meador Inge <meadori at gmail.com> wrote:
> I recently noticed a difference between the way GCC and LLVM treat
> sign extension for parameters and return values on x86-64. I could
> not find a clear answer in the x86-64 ABI [1] concerning whether
> parameters should be sign extended by the caller or callee and
> similarly whether return values
2012 Feb 09
3
[LLVMdev] x86-64 sign extension for parameters and return values
I recently noticed a difference between the way GCC and LLVM treat
sign extension for parameters and return values on x86-64. I could
not find a clear answer in the x86-64 ABI [1] concerning whether
parameters should be sign extended by the caller or callee and
similarly whether return values should be sign extended by the caller
or callee.
Consider a simple 'signed char' division
2012 Oct 22
4
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
So, I'm not really sure if this is the right approach. I'd like some
folks from the LLVM side of things to chime in.
In general, I'm not certain we want to continue growing our dependence
on the signext and zeroext attributes on return types, or whether we
want to do the extension in the frontend instead.
Most of the targets in Clang currently eagerly zext or sext the return
value to