similar to: [LLVMdev] [PATCH] Select correct embedded libclang_rt on Darwin

On Sat, Sep 6, 2014 at 3:40 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 6 September 2014 22:46, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > > I did dig into this further and it seems that they are, in fact, > considered > > part of the RT-ABI :-(. Ive committed a simple conforming > implementation in > > SVN r217322. > >

Hi Tim, I just read this thread and I see that you mentioned the buildbot and my name. > - LLVM test suite enabled in the buildbot and testing ARM64 (Gabor) What exactly I can do to help you with the merge process? Best regards, Gabor Ballabas -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 18 April 2016 at 16:33, Silviu Baranga <Silviu.Baranga at arm.com> wrote: > Doing a grep "eabi" * -R | grep darwin in llvm I found the test divmod-eabi.ll > which uses the triple armv7-apple-darwin-eabi. What format does that have? Certainly not ELF. :) But I didn't mean "has eabi on triple", but "is in none-eabi mode", which may have to check a

On 18 April 2016 at 16:18, Silviu Baranga <Silviu.Baranga at arm.com> wrote: > This doesn't look like something ACLE specific (I can't find it in the ACLE doc). Sorry, I didn't mean it was ACLE, only that you guys were fiddling with macros. :) > This seems to be a generic macro. I think it would make sense to define it > if we know we're emitting ELF. Since the

class Array # break an array up into <size> chunks def chunk(size=1) return self if self.empty? raise ArgumentError if !size.kind_of? Integer y = self.length.divmod(size) rows = (y[1] > 0) ? y[0] + 1 : y[0] arr = Array.new(rows) (0...rows).each do |i| arr[i] = self.slice(size*i, size) end (arr.last.length...size).each { |i| arr.last[i] = nil }

On Mon, Sep 8, 2014 at 1:19 AM, Renato Golin <renato.golin at linaro.org> wrote: > > Why not adjust this instead? > > I was just being conservative. I don't know what else depends on this > library and I don't want to change things outside of my scope. > The current implementations actually return 0. Can you point out where that doesn't hold please? If you

Hi @ll, LLVM-7.0.0-win32.exe contains and installs lib\clang\7.0.0\lib\windows\clang_rt.builtins-i386.lib The implementation of (at least) the multiplication and division routines __[u]{div,mod,divmod,mul}[sdt]i[34] shipped with this libraries SUCKS: they are factors SLOWER than even Microsoft's NOTORIOUS POOR implementation of 64-bit division shipped with MSVC and Windows! The reasons: 1.

"Craig Topper" <craig.topper at gmail.com> wrote: > None of the "si" division routines will be used by x86. That was my expectation too. > They exist for targets that don't support the operations natively. > X86 supports them natively so will never use the library functions. So they SHOULD not be built (or at least not shipped) with the builtins library

Re: Do they really need to be chained with each other or anything else Yes. For 2 reasons. Our architecture lowers udivmem into something with 1 producer and 2 consumers. Reason 1) neither the producers nor the consumers must get reordered. Reason 2) one of the consumers might be missing (either the div or mod consumer might not be present. Yet we need to keep the consuming instruction with side

> On Mar 3, 2016, at 2:00 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 2 March 2016 at 20:03, John McCall <rjmccall at apple.com> wrote: >> We don’t need to. We don't use the intermediary convention’s rules for aggregates. >> The Swift rule for aggregate arguments is literally “if it’s too complex according to >> <foo>, pass it

I need to lower a node into something in the machine that has side effects, i.e. needs a chain. Specifically it's actually UDIVREM. UDIVREM does not have a chain. I can custom lower UDIVREM into the nodes I want, with chain, I can even chain the new nodes and connect them to entry and root with token factors. But then the new nodes are not chained with respect to other nodes, or not chained

Chris, Chris Lattner wrote: > I would love to see any progress in this area. It is clearly an > important thing to tackle, and it is blocking other interesting > improvements in the code generator. It would also allow us to > eliminate a significant amount of weirdness that exists to hack around > this (e.g. switch lowering). we've been working on a whole-function

There must be a better way to write this code: @project_pages, @projects= paginate :project, :per_page => 10, :conditions => ["account_id = ?", account] ?! If only I could pass the sub-collection account = ... @projects = account.project to paginate, instead of letting it extract it with a find :all + sql conditions Alain. -- Posted via

I did it by code preparing into an intrinsic that has side effects. Pseudo instruction would work as well. I'm not sure if glue would help, since the nodes A->B, C->D from example above are not necessarily adjacent. More hooks into the selection DAG builder may be an idea for a LLVM extension. For example in this case, custom allowing for a node to be built with an existing chain would

Hi all, I want to do fuzzing test on Intel x86_64 platform, however I cannot find the shared library for libclang_rt.asan-x86_64-android.so, can anyone tell me where I can find this library? Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170321/36eda3f1/attachment.html>

Hi everyone, (Sorry if I'm asking at the wrong mail listing, but compiler-rt page tells I'd better write on llvm-dev rather than cfe-dev/cfe-users.) I've just built LLVM/Clang+Compiler-rt (Compiler-rt is put inside llvm/projects folder) and tried the -fsanitize option. But strangely the link failed since it cannot find *libclang_rt.san-x86_64.a*. The error message is as

I just tried building the latest clang following the instructions in http://clang.llvm.org/get_started.html, and got this error when trying to compile at test program: /usr/bin/ld: cannot find /home/davem/clang-235334/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory This thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084175.html indicates

Thanks Nicolai! > On Nov 9, 2018, at 02:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > Lots of good stuff in there! I especially like the design for specifying out-of-line predicates. I have a couple of small comments and one major one below. > > > On 09.11.18 02:42, Daniel Sanders via llvm-dev wrote: >> _Passing arbitrary data from

> On Nov 10, 2018, at 03:28, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Thank you for the detailed reply! There's a lot to digest :) Let me try to address most of it. > > > [snip] >>> I also think you should have 'ins' and 'outs' separately; after all, a predicate may have to do a combined check on two matched registers / operands,

On Mar 24, 2008, at 10:47 PM, Christopher Lamb wrote: > I know that this has been discussed (at least in passing) a few > times on the list, but I couldn't locate a bug for it. Have any > architectural plans been made for it? Funny you bring this up. Evan and I were tossing around crazy ideas about this just today. If you're interested, maybe we should get together for