similar to: [LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins.

> I've disassembled the failing MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 and compared it to > the one from the LLVM 3.6.0 test runs. There's nothing obvious. We've removed some useless > 'addiu $sp,$sp,0', eliminated two (seemingly redundant) sign extends, and the addresses of > functions+data has changed slightly. I've investigated further and I'm

> So in summary, each step is ABI compatible with the previous step. The linker will ensure that the end-user doesn't try to do the second step before the first step is finished since it will refuse to link a binary that contains both O32 and O32+fp64. It will produce an O32 binary given a combination of O32+fpxx, and similarly a O32+fp64 binary given a combination O32+fpxx and O32+fp64.

On Wed, Jun 18, 2014 at 2:03 AM, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote: >> Why Imagination Technologies do not offer the latest MIPS ABI document download link just like the ISA docs? > It's something we're considering to do and the documents should be available at some point in the [hopefully] not too distant future. > >> then why GCC disagree with

The term "target" is somewhat overloaded. When llvm-config tells you it was built with the X86 target, that actually includes a variety of closely related architectures, such as x86_64, i386, and so on. Within the x86_64 architecture, there are many individual processor implementations that LLVM understands, such as Skylake, Bulldozer, and many many more. What *clang* means by

On Mon, Jun 23, 2014 at 2:45 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >> There are a lot of MIPS ABIs. > > Yes, and we've discovered that there seem to be incompatible extensions to some of these ABI's too. :) > >> I'm pretty sure Imagination Technologies working up a new abi right now. > > Not exactly. We're not working on any

Hi Tom, I've got a few patches that I'd like to get into 3.5.2 if I can. * r230235 - [mips] Honour -mno-odd-spreg for vector insert/extract when MSA is enabled. o Fixes a failure in the test-suite when -mno-odd-spreg and -mmsa are used together. * r227089 - [mips] Enable arithmetic and binary operations for the i128 data type. o This fixes an instruction selection

But then I should write // CHECK: something // SSE: something // SSE3: something With this feature it can be write // {{[A-Z0-9]+}} : something From: James Y Knight [mailto:jyknight at google.com] Sent: Thursday, May 26, 2016 5:53 PM To: Ehsan Amiri <ehsanamiri at gmail.com> Cc: Elena Lepilkina <Elena.Lepilkina at synopsys.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject:

On Thu, May 26, 2016 at 10:35 AM, Ehsan Amiri via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 7. Wildcard for prefixes - If some statements should be checked > regardless prefix, it should be used //{{*}}, //{{*}}-NEXT, //{{*}}-SAME > and etc. > >> 8. Prefix with regular expressions - If statement should be >> checked if prefix matches some regular

I am working on an LLVM backend for the AVR architecture, and am having troubles working with the codegen layer, trying to get around the quirks of the binary encodings of the AVR ISR. There are several different families of AVR microcontrollers, each with a minimum 'core' instruction set. Each family builds upon (or removes) the core ISR with more instructions or different encodings. My

Thanks for your reply. We are trying to implement a simple Mips-based CPU with just for teaching purpose, so we delete some instructions which are not commonly used, thus the task won't be too hard for students. I am responsible for modifying the compiler so that the compiler won't emit unsupported instructions. In order to avoid "can not select" error, I am trying to expand

YOu have to look for which DAG fragments are not being matched. Then you can create patterns for those using alternate sequences. When you disablea given instruction, don't just disable it, but also look at what pattern it was matching. Then create a patten for that using remaining instructions or in some cases you might have to call a library function, as in the case of floating

Ok, thank you, I will implement it then. As far as I see this optimization should be done in AArch64LoadStoreOptimizer, is it right? From: Eli Friedman [mailto:efriedma at quicinc.com] Sent: Thursday, November 21, 2019 11:55 PM To: Kosov Pavel <kosov.pavel at huawei.com>; LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [ARM] Peephole optimization ( instructions tst +

On 11/11/2017 12:44 PM, Amara Emerson wrote: > >> On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar <proaditya at gmail.com >> <mailto:proaditya at gmail.com>> wrote: >>> >>> The current DAGCombine, being constructed on top of SDAG, has a kind >>> of built-in CSE and automatic DCE. How will things change, if >>> they'll change, in

Hi, I find the pre-built binaries at http://llvm.org/releases very useful. Is there a script available anywhere that does the build, so that I can get a binary built in the very same way, but for a platform not included? (I would like llvm+clang for FC20, something like http://llvm.org/releases/3.6.1/clang+llvm-3.6.1-x86_64-fedora21.tar.xz but for FC20) Thanks! Tomas

Micah, Do you mean we should make GPR64 available to register allocator by calling addRegisterClass? addRegisterClass(MVT::i64, &GPR64RegClass) If we add register class GPR64, type legalization will stop expanding i64 operations because i64 is now a legal type. Then we will probably have to write lots of code to custom-lower unsupported 64-bit operations during legalization. Note that

> On Nov 10, 2017, at 10:19 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 11/10/2017 11:12 AM, Amara Emerson via llvm-dev wrote: >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from

Preamble -------- While working on an IR-level optimisation completely unrelated to register allocation I happened to trigger some really strange register allocator behaviour causing a large regression in bzip2 in spec2006. I've been trying to fix that regression before getting the optimisation patch committed, because I don't want to regress spec2006, but I'm basically fumbling in

hi, Dear Evan Cheng: My cpu is i32 embeded CPU. I define pseudo register pair registers. In mytargetRegisterInfo.td: def T0: RegisterWithSubRegs<"t0",[R0,R1]>; ... def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] In mytargetISelLowering.cpp: I define i1, i8 , i16 and i32 are legal. 1. I still have problem. I save my function return double  value in

enableAdvancedRASplitCost() does the same thing as ConsiderLocalIntervalCost, but as a subtarget option instead of a command-line option, and as I’ve said it doesn’t help because it’s a non-local interval causing the eviction chain (RAGreedy::splitCanCauseEvictionChain only considers the local interval for a single block, and it’s unclear to me how to make it handle a non-local interval). John

On Feb 19, 2009, at 8:26 PM, 任坤 wrote: > hi, Dear Evan Cheng: > > My cpu is i32 embeded CPU. I define pseudo register pair registers. > > In mytargetRegisterInfo.td: > def T0: RegisterWithSubRegs<"t0",[R0,R1]>; > ... > def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] > > In mytargetISelLowering.cpp: > I define i1, i8 ,