similar to: [compiler-rt] Support 128 bits soft-floating point without int128_t support

On 30 January 2018 at 14:12, Kito Cheng via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all: > > I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem > when adding soft float routine for rv32, RISC-V ABI required 128 bits > bits for long double, but it's implemented by int128_t, however rv32 > don't support __int128_t. > > Of

Hi Luke, > was it intentional to leave out both jacob and myself? > [...] > if that was a misunderstanding or an oversight i apologise for raising it. It was definitely not my intention to be non-inclusive, my apologies if that seemed the case! > can i therefore recommend a change, here: > [...] > "This patch adds vscale as a symbolic constant to the IR, similar to >

LLVM Weekly - #218, Mar 5th 2018 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/218>. Welcome to the two hundred and eighteenth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

Thanks @Robin and @Graham for giving some background on scalable vectors and clarifying some of the details! Apologies if I'm repeating things here, but it is probably good to emphasize the conceptually different, but complementary models for scalable vectors: 1. Vectors of unknown, but constant size throughout the program. 2. Vectors of changing size throughout the program. Where (2)

> Dave Yeo wrote: >> Yes that makes sense. Requiring a C99 compliant compiler seems quite reasonable. > Well I'm actually going to be even more reasonable than that. The only bits of C99 that flac will really require is header file > with C99 standard width integers (int8_t, uint8_t, int16_t etc). Erik I would recommend including with the distribution a file for windows

Hi all, I am proposing the integration of a backend targeting the RISC-V ISA. RISC-V is a free and open instruction set architecture that was originally developed at UC Berkeley. Future development of the ISA specification will be handled by the 501(c)(6) non-profit RISC-V Foundation and its members <https://riscv.org/membership/?action=viewlistings>. You can find much more information at

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09.02.2012 21:41, Ben Allison wrote: >>> Dave Yeo wrote: >>>> Yes that makes sense. Requiring a C99 compliant compiler >>>> seems quite >> reasonable. >>> Well I'm actually going to be even more reasonable than that. >>> The only >> bits of C99 that flac will really require is

Hi Duncan- > does this also check that writes are atomic: that they are performed in > one processor operation? Can you elaborate a bit? I don't think volatile has any atomicity requirements. Of course I can make a struct, an int128_t, or whatever volatile (on AVR even an int16_t is updated non-atomically!). Lack of atomicity is one of many problems with using volatile as a basis

I'm interested in what we can do about TBAA for loads that the compiler inserts when optimizing loads into smaller loads (e.g. what SROA does). I'm gonna set the stage by using a small C snippet, because I think C has the best-understood implementation of TBAA among the folks on the list. However, I was unable to actually come up with an example where this inhibits optimizations coming

Hello everybody I am newbie in llvm and compiler, I have some questions about llvm's capability - How large project llvm can compile now? I mean, such as linux kernel or ggc...llvm can build it? especially on the other architecture, ARM or alpha because I must choice one between gcc and llvm to study. In my long tern, I will port some other architecture to gcc or llvm. In fact, I prefer like

Hi all, I have a data frame like this: DF <- data.frame(x = rnorm(10), y = rnorm(10), gr = rep(1:5, 2)) and I make the following xy-plot: library(lattice) xyplot(y ~ x, data = DF, groups = gr, type = "b", col = 1) Is it possible that the two points that belong to the same group specified by DF$gr to have a different color -- that is for each pair of points connected by the line,

> I almost change all the instruction formats. It was a huge work. I am going > to compile and run it now. We have done the similar work[1] on this topic by gcc and we have start migrate our platform to LLVM. In my experience, you need to take care the follow part: * ARMBaseRegisterInfo::getRegPressureLimit * ARMBaseRegisterInfo::getRawAllocationOrder * CalleeSavedRegs *

I almost change all the instruction formats. It was a huge work. I am going to compile and run it now. Best Regards, A. Yazdanbakhsh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PhD. Student School of Electrical and Computer Engineering University of Wisconsin-Madison E-mail: yazdanbakhsh

On Sep 7, 2009, at 6:43 PM, kito wrote: > Hello everybody > > I am newbie in llvm and compiler, I have some questions about llvm's > capability - How large project llvm can compile now? > I mean, such as linux kernel or ggc...llvm can build it? > especially on the other architecture, ARM or alpha > because I must choice one between gcc and llvm to study. > In my long

As previously discussed in an RFC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, the RISC-V backend has i64 as the only legal integer type for the RV64 target. Thanks to variable-sized register class support, this means there is no need for duplication of either patterns or instruction definitions for RV32 and RV64. It's worth noting that RV64I is a different base

Hi, I'm building compiler-rt in a ppc64le machine and it is generating the sanitizers fine but it is not generating the builtin library. I tried to compile it in a x86_64 machine and I got the builtin library generated (libclang_rt.builtins-x86_64.a). Taking a look in a cmake config file from compiler-rt, I saw that ppc64 is not in the supported architecture list to generate the builtin

Hi John, > A "volatile error" indicates a case where a compiler failed to respect > the volatile invariant. The volatile invariant is simply that changing > the optimization level of a strictly conforming C program must not > change the number of dynamic loads or stores to any variable that is > volatile-qualified in the compiler's input. We check this with a hacked

>> Dave Yeo wrote: >>> Yes that makes sense. Requiring a C99 compliant compiler seems quite > reasonable. >> Well I'm actually going to be even more reasonable than that. The only > bits of C99 that flac will really require is header file >> with C99 standard width integers (int8_t, uint8_t, int16_t etc). Erik > > I would recommend including with the

Hi, Sorry if you've seen this message before on llvm.discourse.group or elsewhere -- I've been trying to get to the bottom of this for a while now and asked about this in a few different platforms before. I'm currently trying to debug a bug in a LLVM-generated Wasm code. The bug could be in the code that generates LLVM (rustc) or in the LLVM, I'm not sure yet. LLVM IR and Wasm

Hi John, > > does this also check that writes are atomic: that they are performed in > > one processor operation? > > Can you elaborate a bit? I don't think volatile has any atomicity > requirements. Of course I can make a struct, an int128_t, or whatever > volatile (on AVR even an int16_t is updated non-atomically!). that's not entirely true in practice: if