Displaying 13 results from an estimated 13 matches for "bezanson".
Did you mean:
benson
2013 Apr 06
2
[LLVMdev] Integer divide by zero
A division intrinsic with defined behavior on all arguments would be
awesome! Thanks for considering this.
On Sat, Apr 6, 2013 at 11:27 AM, Joe Groff <arcata at gmail.com> wrote:
> On Saturday, April 6, 2013, Jeff Bezanson wrote:
>>
>>
>> Presumably the optimizer benefits from taking advantage of the
>> undefined behavior, but to get a consistent result you need to check
>> for both zero and this case, which is an awful lot of checks. Yes they
>> will branch predict well, but this...
2013 Apr 06
0
[LLVMdev] Integer divide by zero
On Sat, Apr 6, 2013 at 3:22 PM, Jeff Bezanson <jeff.bezanson at gmail.com>wrote:
> A division intrinsic with defined behavior on all arguments would be
> awesome! Thanks for considering this.
'Tis a good compromise. If there are no objections/concerns, I would like
to move forward with it.
Thanks, Joe!
-Cameron
-----------...
2004 Aug 04
4
Using answering machine in my phone
Is this supported? I have a very simple setup where I have 2 X100P cards and
a TDM10B.
The TDM10B is connected to a phone that has a digital answering machine
built into it.
If I make an inbound call on either X100P interface it gets transferred to
the TDM10B interface.
If I let it ring the TDM10B interface answers the call and the greeting
message of the answering machine
starts. Then shortly
2013 Apr 07
2
[LLVMdev] Integer divide by zero
Hi Cameron,
On 06/04/13 22:52, Cameron McInally wrote:
> On Sat, Apr 6, 2013 at 3:22 PM, Jeff Bezanson <jeff.bezanson at gmail.com
> <mailto:jeff.bezanson at gmail.com>> wrote:
>
> A division intrinsic with defined behavior on all arguments would be
> awesome! Thanks for considering this.
>
>
> 'Tis a good compromise. If there are no objections/concerns,...
2012 Dec 25
2
[LLVMdev] 3.2 version string
LLVM 3.2 came as a nice Christmas present. Just one minor question: I
noticed that the version string (used to name the shared library etc.)
is "3.2svn" instead of the expected "3.2". This violates our build
system's expectations of what things are called. It would be easy for
us to change, but I want to make sure this is not a mistake. I am
fairly certain I downloaded the
2012 Dec 25
0
[LLVMdev] 3.2 version string
Jeff Bezanson <jeff.bezanson at gmail.com> writes:
> LLVM 3.2 came as a nice Christmas present. Just one minor question: I
> noticed that the version string (used to name the shared library etc.)
> is "3.2svn" instead of the expected "3.2". This violates our build
> system&...
2020 Mar 19
2
large slowdown in DAGCombiner::MergeConsecutiveStores
Hello all,
We are seeing a large compiler performance regression in moving from LLVM
6.0.1 to 8.0.1. We have a long function (~50000 instructions) that used to
compile in about a minute but now takes at least an hour. All the time is
in MergeConsecutiveStores, I believe due to super-linear behavior in
analyzing very long chains of stores. For example, this change makes the
problem go away:
```
2012 Mar 01
2
Julia
...s being compiled on the fly
using the LLVM (http://llvm.org) infrastructure. In some ways it
achieves the Holy Grail of languages like R, Matlab, NumPy, ... in
that it combines the speed of compiled languages with the flexibility
of the high-level interpreted language.
One of the developers, Jeff Bezanson, gave a seminar about the design
of the language at Stanford yesterday, and the video is archived at
http://www.stanford.edu/class/ee380/. You don't see John Chambers on
camera but I am reasonably certain that a couple of the questions and
comments came from him.
2013 Apr 06
0
[LLVMdev] Integer divide by zero
On Saturday, April 6, 2013, Jeff Bezanson wrote:
>
> Presumably the optimizer benefits from taking advantage of the
> undefined behavior, but to get a consistent result you need to check
> for both zero and this case, which is an awful lot of checks. Yes they
> will branch predict well, but this still can't be good, for...
2013 Apr 06
3
[LLVMdev] Integer divide by zero
I'm also not fully happy with LLVM's behavior here. There is another
undefined case too, which is the minimum integer divided by -1. In
Julia I can get "random" answers by doing:
julia> sdiv_int(-9223372036854775808, -1)
87106304
julia> sdiv_int(-9223372036854775808, -1)
87108096
In other contexts where the arguments are not constant, this typically
gives an FPE trap.
2012 Mar 08
3
[LLVMdev] Introducing julia, and gauging interest in a julia BOF session at the upcoming LLVM conference in London
...While we have not been active on the LLVM mailing list, we look forward to every new release, and the goodies it brings. We are really looking forward to integrating polly, GPU, autovectorization capabilities, etc. Julia has been in development by a core group consisting of our compiler writer Jeff Bezanson, with Stefan Karpinski and myself contributing the runtime and libraries, and Prof. Alan Edelman focussing on numerical accuracy. We do look forward to meeting with all the folks behind LLVM and the community at large.
Julia was quietly announced in the release notes of LLVM 3.0. It was officially...
2012 Nov 16
1
[LLVMdev] optimizer problem, possibly involving instcombine
Hi all,
Continuing to enjoy LLVM. I'm seeing something strange with the simple
function "f(a,b) = (a+b == b+a)", which before optimization passes has the
following LLVM code:
define i1 @f(i64, i64) {
top:
%a = alloca i64, !dbg !5697
%b = alloca i64, !dbg !5697
store i64 %0, i64* %a, !dbg !5697
store i64 %1, i64* %b, !dbg !5697
%2 = load i64* %a, !dbg !5704
%3 = load
2012 Jun 21
2
[LLVMdev] problem using 128-bit integer on x86-32
Hello everybody,
I'm seeing LLVM (v 3.1) abort when trying to generate code that
multiplies or divides 128-bit integers on x86-32.
Here is a complete example function:
define %jl_value_t* @foo564(%jl_value_t*, %jl_value_t**, i32) {
top:
%3 = load %jl_value_t** %1, align 4, !dbg !5139
%4 = getelementptr inbounds %jl_value_t* %3, i32 0, i32 0, !dbg !5139
%5 = getelementptr %jl_value_t**