search for: dan433584

> On Sep 12, 2014, at 10:27 AM, Dan Gohman <dan433584 at gmail.com> wrote: > > > More generally, I don’t see a compelling reason for LLVM to add intrinsic support for the version you’re proposing. Your choice can easily be expanded into IR, and does not have the wide hardware support (particularly in GPUs) that the IEEE version does. &g...

On Mon, Sep 8, 2014 at 4:22 PM, Dan Gohman <dan433584 at gmail.com> wrote: > It looks a little silly to say this in the case of the integer constant 5, > and there are some semantic gray areas around extra-VM allocation, but the > same thing happens if the add were adding a dynamic integer value, and then > it's difficult to find a...

On 11/1/2012 6:38 PM, Michael Ilseman wrote: > > On Nov 1, 2012, at 3:08 PM, Dan Gohman <dan433584 at gmail.com > <mailto:dan433584 at gmail.com>> wrote: >> >> If the "optimizer" may truly ignore the possibility of NaNs under the >> N flag, this would seem to be ok. However, a trap is outside the >> boundaries of "undefined result". So, whi...

On Nov 1, 2012, at 3:08 PM, Dan Gohman <dan433584 at gmail.com> wrote: > On Tue, Oct 30, 2012 at 8:28 PM, Michael Ilseman <milseman at apple.com> wrote: > > This is similar to how gcc defines -fno-signed-zeros: > "Allow optimizations for floating point arithmetic that ignore the signedness of zero. IEEE arithmetic spec...

...tics, even if I disagree with them. I do think that, if we are using the minnum/maxnum names, we should explicitly note that they are equivalent to C’s fmin/fmax, but not std::min/std::max or Java(script)’s min/max. > > —Owen > > >> On Sep 15, 2014, at 12:26 PM, Dan Gohman <dan433584 at gmail.com> wrote: >> >> Given IEEE-754's sway, and its saying what it does on this point, but given also the popularity of NaN-propagating min and max, how about a compromise? We add intrinsics following the IEEE-754 semantics, but we also follow IEEE-754 (and ARMv8) in renam...

On Fri, Sep 12, 2014 at 3:04 PM, Owen Anderson <resistor at mac.com> wrote: > > On Sep 12, 2014, at 2:24 PM, Owen Anderson <resistor at mac.com> wrote: > > > On Sep 12, 2014, at 10:27 AM, Dan Gohman <dan433584 at gmail.com> wrote: > > >> More generally, I don’t see a compelling reason for LLVM to add intrinsic >> support for the version you’re proposing. Your choice can easily be >> expanded into IR, and does not have the wide hardware support (particularly >> in GPUs) t...

On Mon, Dec 2, 2013 at 4:25 PM, Andrew Trick <atrick at apple.com> wrote: > > On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > Hello llvm-dev, > > > > Following up on the "CodeGen Context" discussion that was started, > attached is patch which implements a pretty minimal skeleton of a CGContext > implementation. The goal is to allow the newly added subtarge...

On Tue, Oct 30, 2012 at 8:28 PM, Michael Ilseman <milseman at apple.com> wrote: > > This is similar to how gcc defines *-fno-signed-zeros:* > "Allow optimizations for floating point arithmetic that ignore the > signedness of zero. IEEE arithmetic specifies the behavior of distinct > +0.0 and -0.0 values, which then prohibits simplification of expressions > such as

On Fri, Apr 26, 2013 at 11:33 PM, Dan Gohman <dan433584 at gmail.com> wrote: > To all, I'm moving on and accepting what appears to be the consensus of > the list, for now. > I want to point out something about this direction that hasn't really come up, but I think deserves some better discussion. I don't think it should be the...

Given IEEE-754's sway, and its saying what it does on this point, but given also the popularity of NaN-propagating min and max, how about a compromise? We add intrinsics following the IEEE-754 semantics, but we also follow IEEE-754 (and ARMv8) in renaming them to minnum and maxnum, to clarify which interpretation these intrinsics are using. -------------- next part -------------- An HTML

Hi Dan, On 25 Apr 2013, at 01:01, Dan Gohman <dan433584 at gmail.com> wrote: > The main alternative approach that's been discussed is to do FastISel to a target-independent opcode set on MachineInstrs, and then do legalization and ultimately the last phase off instruction selection proper after that. The most obvious advantage of using LLVM I...

Hello llvm-dev, Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen can actually switch subtargets within a Module. Comments and questions are invited herewith.

...ilure in LLVM on clang-ppc64-elf-linux2 To: Aaron Ballman <aaron at aaronballman.com>, Adrian Prantl <aprantl at apple.com>, Andrew Kaylor <andrew.kaylor at intel.com>, Artem Belevich <tra at google.com>, Artur Pilipenko <apilipenko at azulsystems.com>, Dan Gohman < dan433584 at gmail.com>, Daniel Jasper <djasper at google.com>, Daniel Sanders < daniel.sanders at imgtec.com>, David Blaikie <dblaikie at gmail.com>, Evgeniy Stepanov <eugeni.stepanov at gmail.com>, Fiona Glaser <escha at apple.com>, Guillaume Papin <guillaume.papin at ep...

On Apr 27, 2013, at 8:10 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Fri, Apr 26, 2013 at 11:33 PM, Dan Gohman <dan433584 at gmail.com> wrote: > To all, I'm moving on and accepting what appears to be the consensus of the list, for now. > > I want to point out something about this direction that hasn't really come up, but I think deserves some better discussion. I don't think it should be the b...

...s it mean user is not expected to use any other stream for stdout, but outs()? Although there is a comment "If you don't want this behavior, don't use outs().", outs() is a static instance which always exists and creates problems, even if not used. - D. 2012/11/29 Dan Gohman <dan433584 at gmail.com> > On Wed, Nov 28, 2012 at 10:54 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > >> Dear all, >> >> Consider there is a program that writes to stdout using two different >> raw_fd_ostream-s: > > > raw_fd_ostream does buffered I/O...

Hi Eli, Recently, I proposed some changes to LLVM to do more lowering of illegal types (like i128 or i17) and other things within the LLVM IR layer, and the proposal was roundly rejected by the LLVM community: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061567.html PNaCl is essentially doing what my proposal described. How do you expect to reconcile the community's desire to avoid

On Nov 1, 2012, at 6:41 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 11/1/2012 6:38 PM, Michael Ilseman wrote: >> >> On Nov 1, 2012, at 3:08 PM, Dan Gohman <dan433584 at gmail.com >> <mailto:dan433584 at gmail.com>> wrote: >>> >>> If the "optimizer" may truly ignore the possibility of NaNs under the >>> N flag, this would seem to be ok. However, a trap is outside the >>> boundaries of "undefined...

On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Hello llvm-dev, > > Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to...

On Apr 24, 2013, at 5:01 PM, Dan Gohman <dan433584 at gmail.com> wrote: > In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework, it is desirable to implement legalization passes as discrete passes. Attached is a patch which implements the beginning of a new type legalization pass, to help motivate discussion....

On Aug 14, 2013, at 3:00 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Standard error is what many tools, including clang for example, use for their --verbose output. This is appropriate because it leaves standard output available for regular output data, which the user may wish to capture in a file or a pipe. Well, at least with the darwi...