similar to: [LLVMdev] [3.7.0] Two late issues with cross compilation to mips

Hi Daniel, I am on a vacation now till the Aug 3 but I can take a look at these problems. What is the most important? As to the issue #3 - do we need to keep compatibility with the old mips-mti-linux-gnu toolchain layout? Simon On Wed, Jul 29, 2015 at 1:08 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > The issues are: > > 1. Almabench has some significant

I believe I've identified the problem with almabench but I haven't found the root cause in the compiler yet. The problem is that a caller saved register ($f14) is being moved across a call and this call sometimes clobbers the value. As a result, the value of the TWOPI constant used in the fmod() calls isn't always 2*PI. According to -print-after-all, the pass that moves the

#1 is the most important but I'm already debugging that. I don't want to interrupt your holiday but if you could look at #3 that would be great. > As to the issue #3 - do we need to keep compatibility with the old mips-mti-linux-gnu toolchain layout? It would be nice to support both the old and new layouts but I doubt that's possible with the current framework (see below). If

To reduce memory consumption clobbered registers are handled with RegisterMask machine operands which contain a bitset of all registers clobbered. - Matthias > On Jul 29, 2015, at 3:00 PM, Daniel Sanders <daniel.sanders at imgtec.com> wrote: > > I believe I've identified the problem with almabench but I haven't found the root cause in the compiler yet. > > The

Thanks. This is making a lot more sense now and it's looking like this issue isn't Mips specific. Here's the IR dump before simple register coalescing (note: I've patched the IR printer to print the contents of the regmask): 4480B %vreg260<def> = LDC1 %vreg253, <cp#3>[TF=6]; mem:LD8[ConstantPool] AFGR64:%vreg260 GPR32:%vreg253 4496B %vreg261<def> = FMUL_D32

Hello Daniel, At the moment we are preparing the patch for disassembling microMIPS 16 bit instructions and it will be on Phabricator tomorrow or on Wednesday. Functionality is implemented in MipsDisassembler::getInstruction where first two bytes are read and decodeInstruction is called with DecoderTableMicroMips16 and only if it fails we read 4 bytes and call decodeInstruction with

Hi Daniel, > (from the context, you might have meant 'tuple' where you've written > 'triple'. I'm answering based on the assumption you meant 'triple') > > I did mean what I wrote. > The GNU triple is already used as a way of encoding a large amount of the > target data in a string but unfortunately, while this data is passed > throughout

Hi Eric, Thanks for getting back to me on this. > I'm not sure I agree with the basic idea of using the target triple as a way of > encoding all of the pieces of target data as a string. I think in a number of > cases what we need to do is either open up API to the back end to specify things, > or encode the information into the IR when it's different from the generic triple.

Good point. The same argument seems to apply to copy() too so I suppose it depends how strict we want to be about it. From: fglaser at apple.com [mailto:fglaser at apple.com] On Behalf Of escha at apple.com Sent: 11 April 2016 20:55 To: Daniel Sanders Cc: Alex Rosenberg; llvm-dev at lists.llvm.org; Carlos Liam Subject: Re: [llvm-dev] Implementing a proposed InstCombine optimization On Apr 11,

Hi all, I plan to deprecate the experimental microMIPS64R6 backend for the 5.0 release and remove it after the release. Currently there are no CPUs that use that particular sub-ISA which makes it difficult to justify the maintenance and parallel development effort. If there was a CPU design produced that did use microMIPS64R6, the backend could be restored from the archive. Any comments or

> I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) I think it's probably safe for IEEE754-2008 conformant platforms because negation was clarified to be a non-arithmetic bit flip that cannot cause exceptions in that specification. However, I'm sure

Actually, GCC will generate non-PIC for n64. Maybe that is a recent addition, but we are using its results. Even if PIC may be faster and smaller code, it seems that non-PIC is still useful for bare-metal. That's the driver of my interest. I guess we can just test what happens when that part of the conditional is removed. As a side note, if it isn't supported then we should probably

> Why isn't the ABI reflected in the triple? Unfortunately, there's no easy answer to that. Some targets are better than others but generally speaking triples are very ambiguous. For example, in (most) GCC mips-linux-gnu/mips64-linux-gnu toolchains both triples produce 32-bit big-endian binaries for MIPS-I by default. Vendors can override the majority of this so it's entirely

Hi, I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select

> > > clang+llvm-3.6.0-rc2-mipsel-linux-gnu.tar.xz > > > All clear for default options. > > > Still running for the other configs. > > > > I just had to kill Searching-dbl.simple and Packing-dbl.simple for the > > mips32 config which were at 65hrs and 15hrs real time respectively. This is > > far in excess of the 15,000s time limit that's

> > (from the context, you might have meant 'tuple' where you've written 'triple'. I'm answering based on the assumption you meant 'triple') > I did mean what I wrote. I thought I ought to check since it's very easy to mix up triples and tuples and the context sounded off. I'm glad I picked the right assumption. > > The proposed TargetTuple

> -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > Sent: 08 July 2015 19:01 > To: Daniel Sanders > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu); Eric Christopher > (echristo at gmail.com); Jim Grosbach (grosbach at apple.com) > Subject: Re: The Trouble with Triples > > On 8 July 2015 at 17:43, Daniel Sanders

Hal, Thank you for finding interest in our work! Please find my answers inlined below. > > ________________________________________ > From: Hal Finkel [hfinkel at anl.gov] > Sent: Monday, December 16, 2013 4:26 PM > To: Radovan Obradovic > Cc: llvmdev at cs.uiuc.edu; chandlerc; Andrew Trick > Subject: Re: [LLVMdev] [RFC] Iterrative compilation framework for Clang/LLVM >

* Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> [2019-10-01 09:44:54 -0400]: > Let's change the example to eliminate suspects: > #include <math.h> > int is_nan(float x) { > /* > The following subclauses provide macros that are quiet (non > floating-point exception raising) > versions of the relational operators, and other comparison

Hi David, What kind of "a lot of out-of-tree changes"? You should push changes incrementally as you do work. Holding onto changes means that many things, not just reformatting, can make them need to be redone. We frequently clean up and rewrite code to make it cleaner and easier to maintain. We are moving to a more strict internal review and pushing of changes and post commit