Displaying 20 results from an estimated 8000 matches similar to: "Custom assembler subset"
2016 Jun 03
2
Custom assembler subset
On Fri, Jun 3, 2016 at 11:53 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
wrote:
> -llvmdev at cs.uiuc.edu, that list isn't in use anymore.
>
> On Wed, Jun 1, 2016 at 4:48 PM, Kenneth Adam Miller via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hello all,
> >
> > I would like to restrain the compiler that I build on my local box from
>
2015 May 12
2
[LLVMdev] how to do make a FP_ROUND need/operattion
Hi Guys,
I and trying to covert a float to a f16.
calling
DAG.getNode(ISD::FP_ROUND, DL, Op->getValueType(0), FloatNode);
will get the error message:"Invalid method to make FP_ROUND node"
what is the "right" way to make this work?
best
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2011 Jan 24
1
[LLVMdev] Question about porting LLVM - code selection without assembler feature
Hello David,
Thanks for your example. Is that means that DAG pattern is consist of LLVM
IR instruction?? I met an example [(set CPURegs:$dst, (OpNode CPURegs:$b,
CPURegs:$c))] of MipsInstrInfo.td, but I can't find correspond LLVM IR
instruction of "set" in "LLVM Language Reference Manual". Is that correspond
to $dst = op $b, $c?? Would you mind to tell me whether there is
2017 Apr 06
2
[GlobalISel][AArch64] Toward flipping the switch for O0: Please give it a try!
On Thu, Apr 6, 2017 at 6:53 AM, Kristof Beyls via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I've been digging a little bit deeper into the biggest performance
> regressions I've observed.
>
> What I've observed so far is:
> * A lot of the biggest regressions are caused by unnecessarily moving
> floating point values through general purpose registers.
2011 Apr 05
4
[LLVMdev] GSoC 2011: Fast JIT Code Generation for x86-64
On Mon, Apr 4, 2011 at 9:50 PM, Eric Christopher <echristo at apple.com> wrote:
>
> On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote:
>
>> [...] Although most optimizations are turned off
>> already and the FastISel instruction selector is used, the "fast" path
>> for first-time code generation is still the bottleneck [...]
>
> This is effectively
2016 Jun 07
4
llvm intrinsics/libc/libm question
On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> Tim,
>
> Currently, I have to do multiple things:
>
> 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct
> naming for RTLIBS.
> 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on
> those to get correct names)
These solve a related but different -
2012 Jun 20
2
[LLVMdev] Back-end: how to test all lowering condition
Dear All,
I am working on a back-end implementation for a new architecture which is provided with its own assembler.
I am currently capable of writing most of the lowering process to generate a decent assembly code.
Under certain circumstances, i.e. depending on the C code, some IR instructions generate a Selection DAG for which I am not implementing a proper lowering, thus resulting in the
2011 Apr 05
0
[LLVMdev] GSoC 2011: Fast JIT Code Generation for x86-64
On Apr 5, 2011, at 2:56 AM, Viktor Pavlu wrote:
> On Mon, Apr 4, 2011 at 9:50 PM, Eric Christopher <echristo at apple.com> wrote:
>>
>> On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote:
>>
>>> [...] Although most optimizations are turned off
>>> already and the FastISel instruction selector is used, the "fast" path
>>> for first-time
2012 Oct 30
1
[LLVMdev] Any plan to add MIN/MAX isd node?
Hi Duncan,
Yes, exactly. However, we need define Opcode MIN/MAX
Into ISDOpcodes.h. Do you like to add those two definitions
Into the tree?
Thanks,
Yin
-----Original Message-----
From: Duncan Sands [mailto:duncan.sands at gmail.com] On Behalf Of Duncan Sands
Sent: Tuesday, October 30, 2012 12:10 PM
To: Yin Ma
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Any plan to
2018 Jul 30
9
GlobalISel design update and goals
Hi all,
Over the past few months we’ve been doing work on the foundations for the next stages of GlobalISel development. In terms of changes from this time last year, the IR translator, the legalizer, and instruction selector have seen moderate to major changes. The most significant of these was the change to the legalizer API, allowing targets to use predicates to express legality, which gives
2012 Jun 20
1
[LLVMdev] Back-end: how to test all lowering condition
Dear Tom,
thank you for your reply. What you suggest is something I was considering doing, however there still no solution to my Problem2. How do I test the ISD instructions if I can only write IR instructions?
-----Original Message-----
From: Tom Stellard [mailto:thomas.stellard at amd.com]
Sent: Wednesday, June 20, 2012 4:14 PM
To: Christian Nastasi
Cc: llvmdev at cs.uiuc.edu
Subject: Re:
2011 Apr 04
0
[LLVMdev] GSoC 2011: Fast JIT Code Generation for x86-64
On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote:
> I currently work on generating fast cycle-accurate simulators[2]. For
> this, our institute has implemented a two-part adaptive compilation
> scheme using the LLVM-JIT. Although most optimizations are turned off
> already and the FastISel instruction selector is used, the "fast" path
> for first-time code generation is
2018 Jul 31
2
GlobalISel design update and goals
> On 30 Jul 2018, at 16:04, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Hi Amara,
>
> Thanks for sharing the plan going forward.
>
> Inlined a couple of comments.
>
> 2018-07-30 7:01 GMT-07:00 Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>:
>> Hi all,
>>
>>
2016 Jun 14
2
llvm intrinsics/libc/libm question
If I do
T.getArch() == xxx
TLI.setUnavailable(LibFunc::copysign)
then this works at generating a call instead of not being able to select
the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other
LibFunc functions (such as floor, etc... these generate call just fine)?
Thanks,
Ryan
On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
2008 Jul 14
2
[LLVMdev] Regarding ARM CodeGen
Hi all,
I am using LLVM compiler and CodeGen for generating ARM binaries.
I was going through the code for ARM backend. I noticed that the ARM
Condition field( Bits 31-28) is generated by converting the conditions used
in icmp and branch. For example, if I have following C Code
int a,b,c,d;
c = a+b;
if(c==0)
d = a + 10;
Then I get ( Assembly Instructions with opcodes only)
add
*cmp*
2012 Jun 20
0
[LLVMdev] Back-end: how to test all lowering condition
On Wed, Jun 20, 2012 at 01:50:51PM +0000, Christian Nastasi wrote:
> Dear All,
> I am working on a back-end implementation for a new architecture which is provided with its own assembler.
> I am currently capable of writing most of the lowering process to generate a decent assembly code.
> Under certain circumstances, i.e. depending on the C code, some IR instructions generate a
2018 Aug 03
2
GlobalISel design update and goals
> On 2 Aug 2018, at 14:50, Quentin Colombet <quentin.colombet at gmail.com> wrote:
>
> Hi Daniel,
>
> 2018-07-31 8:40 GMT-07:00 Daniel Sanders <daniel_l_sanders at apple.com>:
>>
>>
>> On 30 Jul 2018, at 16:04, Quentin Colombet via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi Amara,
>>
>> Thanks for
2013 Jun 24
1
[LLVMdev] Matching patterns
I'm trying to create a TableGen pattern to match extract_vector_elt.
My pattern looks like this:
(set i32:$dest, (extract_vector_elt v16i32:$src, i32:$index))
However, when I compile, I get an error:
error: Variable not defined: 'extract_vector_elt'
However, if I omit the rule and attempt to compile something that uses
this functionality with clang, I get this error, which
2011 Apr 01
4
[LLVMdev] GSoC 2011: Fast JIT Code Generation for x86-64
Hi All,
I'd like to propose a fast path through code generation for x86-84 in
the JIT execution engine as part of 2011's Google Summer of Code
program.
While the LLVM-JIT is very popular as a first try at jitting
programming languages, projects have abandoned the LLVM-JIT when
disappointed with the overall runtime. The problem is, that the
benefit of faster execution is traded for longer
2015 Feb 05
8
[LLVMdev] type legalization/operation action
Dear there,
I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well.
My initial thought is:
(1)
I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set.
but looks it is not