Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Error: llc crashes (LLVM 3.1)"
2011 Mar 24
0
[LLVMdev] mblaze backend: unreachable executed
> what does "refuses to compile" mean? I.e. what error do you get?
>
Specifically I get this message when compiling with the default -mattr:
Call result #2 has unhandled type i32
UNREACHABLE executed at CallingConvLower.cpp:162!
0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38
1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254
2
2011 Mar 24
0
[LLVMdev] mblaze backend: unreachable executed
>
> what does "refuses to compile" mean? I.e. what error do you get?
>
Specifically I get this message when compiling with the default -mattr:
Call result #2 has unhandled type i32
UNREACHABLE executed at CallingConvLower.cpp:162!
0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38
1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254
2
2011 Mar 15
0
[LLVMdev] mblaze backend: unreachable executed
Hello,
Am 15.03.2011 um 19:27 schrieb Josef Spjut:
> Does anyone know what common causes of "UNREACHABLE executed!"
> messages are and what this message in particular means? The full
> error message is the following:
>
> UNREACHABLE executed!
> 0 llc 0x0000000100936ae2 PrintStackTrace(void*) + 34
> 1 llc 0x0000000100937603
2011 Mar 15
3
[LLVMdev] mblaze backend: unreachable executed
Hello,
I am working on a backend for a custom ISA that is somewhat similar to the MicroBlaze ISA so I've decided to use that as a starting point. I am trying to compile a custom ray tracer (lots of floating point) and the llvm-g++ frontend generates an fneg instruction which is not supported by the MBlaze backend in the 2.8 release. I added code to emit an fneg assembly instruction and now
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 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 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 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 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 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 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 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 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 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 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 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: