Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] passing args in registers, pointers vs integers"
2009 Feb 13
0
[LLVMdev] Using CallingConvLower in ARM target
On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote:
> Although it's not generally needed for ARM's use of CCCustom, I return
> two bools to handle the four possible outcomes to keep the mechanism
> flexible:
>
> * if CCCustomFn handled the arg or not
> * if CCCustomFn wants to end processing of the arg or not
+/// CCCustomFn - This function assigns a location for Val,
2009 Feb 13
2
[LLVMdev] Using CallingConvLower in ARM target
On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote:
>
>> Although it's not generally needed for ARM's use of CCCustom, I return
>> two bools to handle the four possible outcomes to keep the mechanism
>> flexible:
>>
>> * if CCCustomFn handled the arg or not
>>
2009 Feb 13
2
[LLVMdev] Using CallingConvLower in ARM target
Although it's not generally needed for ARM's use of CCCustom, I return
two bools to handle the four possible outcomes to keep the mechanism
flexible:
* if CCCustomFn handled the arg or not
* if CCCustomFn wants to end processing of the arg or not
I placed the "unsigned i" outside those loops because i is used after
the loop. If there's a better index search pattern, I'd
2009 Feb 13
0
[LLVMdev] Using CallingConvLower in ARM target
On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote:
> On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com>
> wrote:
>>
>> On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote:
>>
>>> Although it's not generally needed for ARM's use of CCCustom, I
>>> return
>>> two bools to handle the four possible outcomes to keep
2009 Feb 09
0
[LLVMdev] Using CallingConvLower in ARM target
Thanks Sandeep. I did a quick scan, this looks really good. But I do
have a question:
+/// CCCustomFn - This function assigns a location for Val, possibly
updating
+/// all args to reflect changes and indicates if it handled it. It
must set
+/// isCustom if it handles the arg and returns true.
+typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT,
+ MVT
2009 Feb 14
2
[LLVMdev] Using CallingConvLower in ARM target
ARMTargetLowering doesn't need case #1, but it seemed like you and Dan
wanted a more generic way to inject C++ code into the process so I
tried to make the mechanism a bit more general.
deep
On Fri, Feb 13, 2009 at 2:34 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote:
>
>> On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng
2009 Feb 14
0
[LLVMdev] Using CallingConvLower in ARM target
On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote:
> ARMTargetLowering doesn't need case #1, but it seemed like you and Dan
> wanted a more generic way to inject C++ code into the process so I
> tried to make the mechanism a bit more general.
Ok. Since ARM doesn't need it and it's the only client, I'd much
rather have CCCustomFn just return a single bool indicating
2009 Feb 14
2
[LLVMdev] Using CallingConvLower in ARM target
Sure. Updated patches attached.
deep
On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote:
>
>> ARMTargetLowering doesn't need case #1, but it seemed like you and Dan
>> wanted a more generic way to inject C++ code into the process so I
>> tried to make the mechanism a bit more
2009 Feb 07
2
[LLVMdev] Using CallingConvLower in ARM target
I think I've got all the cases handled now, implementing with
CCCustom<"foo"> callbacks into C++.
This also fixes a crash when returning i128. I've also included a
small asm constraint fix that was needed to build newlib.
deep
On Mon, Jan 19, 2009 at 10:18 AM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote:
2009 Feb 14
0
[LLVMdev] Using CallingConvLower in ARM target
Sorry left a small bit of cruft in ARMCallingConv.td. A corrected
patch it attached.
deep
On Fri, Feb 13, 2009 at 6:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote:
> Sure. Updated patches attached.
>
> deep
>
> On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>>
>> On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote:
2009 Jan 17
2
[LLVMdev] Using CallingConvLower in ARM target
On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com> wrote:
>
> One problem with this approach is that since i64 isn't legal, the
> bitcast would require custom C++ code in the ARM target to
> handle properly. It might make sense to introduce something
> like
>
> CCIfType<[f64], CCCustom>
>
> where CCCustom is a new entity that tells the
2009 Feb 18
0
[LLVMdev] Using CallingConvLower in ARM target
On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote:
> /// Information about how the value is assigned.
> - LocInfo HTP : 7;
> + LocInfo HTP : 6;
>
> Do you know why this change is needed? Are we running out of bits?
HTP was't using all of these bits. I needed the hasCustom bit to come
from somewhere unless we wanted to grow this struct, so I
2009 Feb 16
3
[LLVMdev] Using CallingConvLower in ARM target
Thanks.
More questions :-)
/// Information about how the value is assigned.
- LocInfo HTP : 7;
+ LocInfo HTP : 6;
Do you know why this change is needed? Are we running out of bits?
- NeededStackSize = 4;
- break;
- case MVT::i64:
- case MVT::f64:
- if (firstGPR < 3)
- NeededGPRs = 2;
- else if (firstGPR == 3) {
- NeededGPRs = 1;
- NeededStackSize = 4;
-
2009 Feb 18
2
[LLVMdev] Using CallingConvLower in ARM target
This time with the test cases actually attached.
deep
On Tue, Feb 17, 2009 at 4:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote:
> On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote:
>> /// Information about how the value is assigned.
>> - LocInfo HTP : 7;
>> + LocInfo HTP : 6;
>>
>> Do you know why this change
2009 Feb 26
0
[LLVMdev] Using CallingConvLower in ARM target
Sorry I haven't gotten back to you earlier. I have been busy.
I ran some MultiSource/Benchmark earlier today. Looks like there are
some failures: Fhourstones-3.1, Fhourstones, McCat/08-main, MiBench/
consumer-lame, Olden/Power, Olden/voronoi, mafft/pairlocalign, and
sim. Are you able to test them on your end?
Evan
On Feb 17, 2009, at 4:42 PM, Sandeep Patel wrote:
> This time with
2009 Jan 19
0
[LLVMdev] Using CallingConvLower in ARM target
On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote:
> On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com> wrote:
>>
>> One problem with this approach is that since i64 isn't legal, the
>> bitcast would require custom C++ code in the ARM target to
>> handle properly. It might make sense to introduce something
>> like
>>
>>
2009 Feb 28
3
[LLVMdev] Using CallingConvLower in ARM target
I'm not currently setup to be able to run the A/B comparison tests
that test-suite relies upon.
Fhourstones-3.1 looks to be the simplest. If you can send me the two
.o files from either EABI or Darwin, I can dig into why this went
wrong for you.
deep
On Thu, Feb 26, 2009 at 3:53 PM, Evan Cheng <echeng at apple.com> wrote:
> Sorry I haven't gotten back to you earlier. I have
2009 Apr 17
0
[LLVMdev] Using CallingConvLower in ARM target
On Apr 16, 2009, at 2:52 AM, Sandeep Patel wrote:
> After wasting an inordinate amount of time trying to get test-suite to
> run on arm-apple-darwin so I could reproduce your results, attached is
> a patch that fixes the small copy&paste error of having 8-byte
> alignment for stack-allocated f64s instead of the proper 4-byte. I've
> updated the patch to the top of trunk
2009 Apr 17
1
[LLVMdev] Using CallingConvLower in ARM target
Done! Sandeep, this is really a great change. I had seen the
discussion of it but hadn't looked at the details until now. Thanks a
lot for contributing this.
While I was reviewing it, I found some a few small nit-picky things to
clean up (mostly in comments and whitespace). Sorry -- I'm a bit
compulsive that way! I will commit those changes in a few minutes.
Other than
2009 Apr 16
2
[LLVMdev] Using CallingConvLower in ARM target
After wasting an inordinate amount of time trying to get test-suite to
run on arm-apple-darwin so I could reproduce your results, attached is
a patch that fixes the small copy&paste error of having 8-byte
alignment for stack-allocated f64s instead of the proper 4-byte. I've
updated the patch to the top of trunk changes as well.
deep
On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel