search for: divmod

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 few more Triple properties. For all the others (Linux, BSD), the __E...

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 } if arr.last.length < size arr end end put it in /lib and add require ''...

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. subroutine matroschka, 2. "C" implementation! JFTR: the target processor "i386" (...

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

> When you decide to work on MachO/Darwin, I want to discuss the problems with ELF vs. EABI (http://llvm.org/PR18187). Well, I'm doing it now to some extent (working on disentangling the ARM backend's various uses of isTargetIOS, isTargetDarwin, isMoonFull as a starting-point). The thing is, the main advantage of Triples is that they're largely GCC-compatible. Without that

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. > >

...on 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 effects. The only way to achieve is to add it into the chain. Problem here: divmod does not have a chain. I scanned other architectures, haven't found an example where somebody creates a chain out of thin air. Do you know any? On Thu, Jul 16, 2020 at 10:54 AM Tim Northover <t.p.northover at gmail.com> wrote: > On Thu, 16 Jul 2020 at 16:44, Hendrik Greving via llvm...

...ersity of technology in the recent past. our approach considers ssa graphs and is based on a problem transformation to a specialized quadratic assignment problem (pbqp). in contrast to previous work [1], the technique is flexible enough to cope with general DAG patterns such as pre/postincrement or divmod patterns. the instruction selector is a drop-in replacement for the original implementation (llvm 2.1). we've used the ARM backend for evaluation and obtained quite encouraging results: speedups are up to 10% for SPEC/Mibench and up to 57% for simple loop kernels. the compile time increase...

...to an NMakefile, for use with ML.EXE. For the optimisations see the patch I sent last week. Since Howard Hinnant is NO MORE with LLVM: who is the CURRENT code owner and reviewer for the builtins library, especially for x86? I'm asking this SIMPLE question now for the 3rd time! I also have __udivmoddi3: adding the pointer to the remainder as argument and 4 more instructions will turn it into __udivmoddi4. Compiling them with MSVC is of course easy to achieve: remove the MASM/ML statements, put the assembler source inside an __asm block, and add a function definition with __declspec(naked) Bu...

Hi All, I had a function from the pragprog book in my application_helper.rb file. Here it is: def format_price(amount) dollars, cents = amount.divmod(100) sprintf("$%d.%02d", dollars, cents) end I call this function in my view quite simply like this: <td><%= format_price(hard_product.price_ca) %></td> This was working fine until today, suddenly for now apparent reason, it gives an error: undefined method `...

> 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

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

...vironment's libc can be problematic. > > I wasn't proposing we signal, but that we return zero, instead of the > argument. > Fair enough. However, the point is that emulating GCC's behavior of the exception is what I was referring to. > Today we return either zero (in divmod/div/mod) or the argument (when > calling div0 directly), and that's just wrong. Quoting the RTABI: 1. int __aeabi_idiv0(int return_value); long long __aeabi_ldiv0(long long return_value); The *div0 functions: 􏰁 Return the value passed to them as a parameter. Is...

...recent past. our approach > considers ssa graphs and is based on a problem transformation to a > specialized quadratic assignment problem (pbqp). in contrast to > previous > work [1], the technique is flexible enough to cope with general DAG > patterns such as pre/postincrement or divmod patterns. > > the instruction selector is a drop-in replacement for the original > implementation (llvm 2.1). we've used the ARM backend for evaluation > and > obtained quite encouraging results: speedups are up to 10% for > SPEC/Mibench and up to 57% for simple loop kernels...

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

...39;t deal with multi-result instructions very well. Every time this has been raised on the list w.r.t SelectionDAG the solution has boiled down to 'use C++ instead' and it would be good to fix that so that things like UADDO are representable. You can write a rule that matches something like divmod at the top-level using the 'set' operator: >> (set $D1, $D2, (divmod $A, $B)) >> but as soon as it's not the top-level, it gets really ugly fast even using pseudo-nodes: >> (set (outs $D1, $D2), (sext (result (G_DIVMOD $A, $B):$T, 0)), >>...

...>> I’m not sure why you say that. We already do have parameter ABI override >> attributes with target-specific behavior in LLVM IR: sret and inreg. > > Their meaning is somewhat confused and hard-coded in the back-end. I > once wanted to use inreg for lowering register-based divmod in > SelectionDAG, but ended up implementing custom lowering in the ARM > back-end because inreg wasn't used correctly. It's possible that now > it's better, but you'll always be at the mercy of what the back-end > does with the attributes, especially in custom lowering....

...39;t deal with multi-result instructions very well. Every time this has been raised on the list w.r.t SelectionDAG the solution has boiled down to 'use C++ instead' and it would be good to fix that so that things like UADDO are representable. You can write a rule that matches something like divmod at the top-level using the 'set' operator: (set $D1, $D2, (divmod $A, $B)) but as soon as it's not the top-level, it gets really ugly fast even using pseudo-nodes: (set (outs $D1, $D2), (sext (result (G_DIVMOD $A, $B):$T, 0)), (sext (result $T, 1))) In this e...

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