Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Troubling promotion of return value to Integer ..."
2008 May 15
0
[LLVMdev] Troubling promotion of return value to Integer ...
On May 14, 2008, at 10:43 AM, Alireza.Moshtaghi at microchip.com wrote:
> In this thread I’m trying to merge two email threads into one,
> because both discuss the same problem that’s troubling us and I
> would like to reach a conclusion on what would be the best approach.
> To minimize the size of this thread I only mention the subject of
> the other two threads:
> (1)
2008 May 13
0
[LLVMdev] trouble with 32-bit promotion of return value
There is a FIXME part in SelectionDAGLowering::visitRet() that is giving
us trouble. And I would like to know how the community has planned for
addressing this problem.
The current implementation assumes that all C calling conventions
require the return value of integer types in the largest register class
(for most ports 32-bit). However, this is not the case for our port. We
have two register
2008 May 15
2
[LLVMdev] Troubling promotion of return value to Integer ...
I know that many ABIs require this for performance purpose, but I
haven't seen anything in the standard that suggests promotion of return
value to integer. Furthermore, I think the LLVM is supposed to be
independent of language. So I'm not sure if SelectionDAGLowering is the
right place for this promotion to begin with, TargetLowering class seems
more logical; but I'm not sure how.
2008 May 16
0
[LLVMdev] Troubling promotion of return value to Integer ...
On May 14, 2008, at 10:43 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com
> wrote:
> In this thread I’m trying to merge two email threads into one,
> because both discuss the same problem that’s troubling us and I
> would like to reach a conclusion on what would be the best approach.
> To minimize the size of this thread I only mention
2008 May 19
2
[LLVMdev] Troubling promotion of return value to Integer ...
But they both follow the same calling convention. There are two
possibilities in the caller:
1) Call node returns sizeof(int) or larger: in this case there is no
truncation.
2) Call node returns smaller than sizeof(int): in this case callee
always has to return an int so it has to consistently either sign extend
or zero extend because int is either signed or unsigned consistently for
that port.
2008 May 12
3
[LLVMdev] LLVM Exception Handling Changes
I just took a closer read of Chris' "LLVM Exception Handling Changes"
document and have some comments.
[...]
> This bloats the code and is quite slow: it's not feasible to use
> hardware traps to implement these checks.
It's not totally infeasible. An approach similar to what if-conversion
does could implement this. I'm not necessarily advocating this, I'm
2008 May 29
4
[LLVMdev] Troubling promotion of return value to Integer ...
On May 28, 2008, at 11:53 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com
> wrote:
>> Ok. We already have this, with the 'signext' attribute. This code:
>>
>> signed char g();
>> signed char foo(){
>> return g();
>> }
>>
>> compiles into:
>>
>> define i8 @foo() signext nounwind {
2008 May 29
0
[LLVMdev] Troubling promotion of return value to Integer ...
> On further reflection, I actually like the idea of adding 4 attributes
> better than adding knowledge of "int" into TargetData. "int" is a C
> notion that doesn't really belong in TargetData, and it is better for
> the optimizers to have the front-end expose the implicit promotions.
This is very true and indeed applicable to this problem...
So I have to
2008 May 19
0
[LLVMdev] Troubling promotion of return value to Integer ...
Correction:
The analysis I made regarding the callers knowledge of sign/zero
extension of return value is flawed. So I take it back.
Never the less, I don't see how adding attributes would resolve this
problem either.
Ali
________________________________
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Alireza.Moshtaghi at microchip.com
2008 May 23
1
[LLVMdev] Troubling promotion of return value to Integer ...
Chris,
Regardless of the optimization problem that we had discussions before, I
think we all agreed that promotion of return value should take place in
the front-end...
Now I have a suggestion:
In the message below you laid out the suggested IR for "char foo()" when
its return value is promoted to i32 in front-end.
You have applied the promotion both at the definition of function and
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.
2008 May 23
3
[LLVMdev] Troubling promotion of return value to Integer ...
On May 20, 2008, at 2:16 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com
> wrote:
>
>> Ok, I'm not sure what issue you mean. Can you restate?
>
> I'm referring to your statement (below) where you say "there needs
> to be
> some attribute (or something) on foo".
Ok.
> What I don't understand is I
>
2009 Mar 04
7
[LLVMdev] promotion of return value.
Below I have pasted the latest design that we discussed...
Now we would like to pick it up and do the implementation.
1) Is there any last change that we would like to add?
2) Has anyone been working on it? I haven't seen any thing new in the
code so I assume the answer is no...
Thanks
Alireza Moshtaghi
Senior Software Engineer
Development Systems, Microchip Technology
Subject:
Troubling
2008 May 16
4
[LLVMdev] Troubling promotion of return value to Integer ...
Chris,
I did not quite understand the "The bad thing about ..." part of your
argument. I'm not sure which of the two scenarios are you comparing
(promoting in FrontEnd vs BackEnd) or (promotion to int vs i32)
Regardless, I agree with you and shap that promotions should take place
in the FrontEnd and this is my reason:
The standard allows calling a function without prototype and
2008 Jun 10
2
[LLVMdev] Troubling promotion of return value to Integer ...
I think the "answer" is yes. Given the attributes are a bitfield, it
would be difficult to encode any arbitrary type. I am happy with just
adding sign_ext_from_i1 and zero_ext_from_i1 for now. That's
progress! :-)
Evan
On Jun 9, 2008, at 12:43 PM, Alireza.Moshtaghi at microchip.com wrote:
>
>>
>> Yes, this would be much nicer. The only issue is that
2008 May 28
2
[LLVMdev] Troubling promotion of return value to Integer ...
On May 27, 2008, at 3:33 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com
> wrote:
> Chris,
> I see, so in deed the front-end sets the attributes on the declaration
> of the called function; which in theory is also available to the
> caller
> through the CALL node.
Right.
> Now here is what I think:
> I agree that 4 attributes are
2009 Mar 12
0
[LLVMdev] promotion of return value.
Previously we talked about adding new attributes to function to identify the promotion class.
> sign_ext_from_i8, sign_ext_from_i16
> zero_ext_from_i8, zero_ext_from_i16
Aren't these attributes more applicable to return value? of course then the question would be if they are also applicable to parameters too? (because we use same attributes for parameters and return value)? or
2009 Mar 13
4
[LLVMdev] promotion of return value.
Some targets want to do the promotion in the callee and some in the
caller. Now what you are discussing in your bug is we shouldn't do in
both...
Now the tricky part is that many targets (not for the sake of promotion,
but for the sake of performance) return a smaller value in a larger
register (say if the function is to return char, they return it in 32
bit register);
So they are effectively
2008 Jun 04
4
[LLVMdev] Troubling promotion of return value to Integer ...
On May 29, 2008, at 10:30 AM, Alireza.Moshtaghi at microchip.com wrote:
>
>
> 4) There will be 4 new function attributes:
> sign_ext_from_i8, sign_ext_from_i16
> zero_ext_from_i8, zero_ext_from_i16
> These attributes will be placed on the function CALL node by
> front-end
> to inform the backend about such promotions and enable optimization
> of
> return
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: