search for: fast

...ax gave TSI as: "xxxx" <<< DCS: 83 00 86 90 00 DCS with final frame tag In state 9 DCS: Can receive fax Selected data signalling rate: V.29, 9600bps 2D coding OK Scan line length: 215mm Recording length: A4 (297mm) Minimum scan line time: 5ms Get at 9600 Changed from phase 3 to 5 Fast carrier up Fast carrier down Fast carrier up Coarse carrier frequency 1699.90 (64) Training error 56.874846 Training succeeded (constellation mismatch 44.212022) Fast carrier trained Fast carrier down Trainability test failed - longest run of zeros was 14 >>> FTT: 44 Fast carrier up Traini...

New patches with review feedback incorporated: * Changed single letter flags to short abbreviations ('S' ==> 'nsz') * Indentation fixes * Comments don't state function names -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type: application/octet-stream Size: 4937 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/2e3c515f/attachment.obj> -------------- next part -------------- -------------- next part -------------- A non-text...

...4 PM, Michael Ilseman <milseman at apple.com> wrote: > New patches with review feedback incorporated: > * Changed single letter flags to short abbreviations ('S' ==> 'nsz') > * Indentation fixes > * Comments don't state function names > > <0002-Fast-math-flags-added-to-FPMathOperator.patch> > <0003-Fast-math-interfaces-for-Instructions.patch> > <0004-Fast-math-flags-for-LLVM-IR-parsing-and-printing.patch> > <0005-Fast-math-flags-for-the-bitcode.patch> > <0006-Fast-math-test-case-for-bitcode-and-textual-readi...

Hi all, This is about https://reviews.llvm.org/D26708 Currently when the command-line switch '-ffast-math' is specified, the IR-level fast-math-flag 'fast' gets attached to appropriate FP math instructions. That flag acts as an "umbrella" to implicitly turn on all the other fast-math-flags ('nnan', 'ninf', 'nsz' and 'arcp'): http://llvm.org/d...

...Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Warren Ristow" <warren.ristow at sony.com> > Cc: llvm-dev at lists.llvm.org > Sent: Tuesday, November 15, 2016 11:10:48 PM > Subject: Re: [llvm-dev] RFC: Consider changing the semantics of > 'fast' flag implying all fast-math-flags > Hi, > > On Nov 15, 2016, at 5:15 PM, Ristow, Warren via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: > > > Hi all, > > > This is about https://reviews.llvm.org/D26708 > > > Currently when the comm...

Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. + bool any() { + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | + AllowReciprocal; + } Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: SubclassOptionalData = (SubclassOptionalData & ~BitToSet) | (B * BitToSet); This is likely one iota slower.. but it sure is easier to get the intent. B ? SubclassOptionalData |= BitToSet : SubclassOptionalData &= ~BitToSet; Otherwi...

...iprocal aspect in the patch, but of course that wasn't useful without doing something about (1). Regarding (1), over at https://reviews.llvm.org/D26708#596610, David made the same point that it should be done in Clang. I can understand that, but I wonder whether having the concept of the 'fast' flag in the IR that implies all the other FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture. For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags) the fast-math flags '...

...inf', etc.? They definitely need to be documented. > I think it does make sense to expand them to be more readable. Also, the textual representation doesn't have to precisely follow the internal names. What about: nnan : no nans ninf : no infs nsz : no signed zeros ar: allow reciprocal fast : unsafe algebra (and implicitly all the others) I'll get started on documentation. > Evan > > On Nov 15, 2012, at 10:17 AM, Michael Ilseman <milseman at apple.com> wrote: > >> Attached are some patches for adding in an IR-level mechanism for representing fast-math f...

...-Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi Amini via llvm-dev Sent: Wednesday, November 16, 2016 8:55 AM To: Ristow, Warren <warren.ristow at sony.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags On Nov 15, 2016, at 11:59 PM, Ristow, Warren <warren.ristow at sony.com<mailto:warren.ristow at sony.com>> wrote: Hi, Thanks for the quick feedback. I see your points, but I have a few questions/comments. I'll start at the end of the prev...

Hi all, In a mailing-list post last November: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html I raised some concerns that having the IR-level fast-math-flag 'fast' act as an "umbrella" to implicitly turn on all the lower-level fast-math-flags, causes some fundamental problems. Those fundamental problems are related to situations where a user wants to disable a portion of the fast-math behavior. For example, to enable all th...

This is of course not homework. I am trying to understand how fast math optimizations work in llvm. When I compared IR for both the programs, the only thing I have noticed is that fdiv and fmul are replaced with fdiv fast and fmul fast. Not sure what happens in fdiv fast and fmul fast. I feel that its because d/max is really small number and fast-math does not car...

Mehdi, Teresa, Not sure if this is caused by one of your recent commits, or by someone else's, please excuse me if that's unrelated to your work... http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/542/steps/check-llvm%20asan/logs/stdio ==26383==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x000002ef41d8 at pc 0x0000009d1aa5 bp 0x7ffd0cd72b50 sp 0x7ffd0cd72b48 READ of size 4 at 0x000002ef41d8 thread T0 #0 0x9d1aa4 in getValue /mnt/b/sanitizer-buildbot3/sanitizer...

...Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. > > + bool any() { > + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | > + AllowReciprocal; > + } > Will do. > Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: > > SubclassOptionalData = > (SubclassOptionalData & ~BitToSet) | (B * BitToSet); > This is an existing pattern that's used elsewhere in the file, so I had assumed it was well understood and preferred. > This is likely one...

...t; ... except that Warren’s proposal that started this discussion seems to imply that he > > has a use case that requires reciprocals to be turned off separately. > > Just to close this loose end, yes I have a use case. > > Specifically, we have a customer that turns on '‑ffast‑math', but was getting a runtime failure due to the reciprocal-transformation being done. Can you elaborate what kind of runtime failure is the reciprocal transformation triggering? — Mehdi > They don't want turn off fast‑math because they like the performance improvement, and can...

..., however I think you should use logical ors here not bitwise. >> >> + bool any() { >> + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | >> + AllowReciprocal; >> + } >> > > Will do. > >> Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: >> >> SubclassOptionalData = >> (SubclassOptionalData & ~BitToSet) | (B * BitToSet); >> > > This is an existing pattern that's used elsewhere in the file, so I had assumed it was well understood and preferred...

Attached are some patches for adding in an IR-level mechanism for representing fast-math flags, as discussed in my prior RFC. Patches include infrastructure, API support, textual and bitcode reader/writer support, example optimization, and test cases. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.p...

Rxfax answers, makes handshake, and crashes once the page starts to send. It receives a .tif file of 8 bytes. Asterisk dumps core - gdb shows : #0 0x281fd86c in t4_rx_putbit () from /usr/local/lib/libspandsp.so.0 #1 0x281fea3c in fast_putbit () from /usr/local/lib/libspandsp.so.0 #2 0x28208324 in decode_baud () from /usr/local/lib/libspandsp.so.0 #3 0x2820893f in process_baud () from /usr/local/lib/libspandsp.so.0 #4 0x28209266 in v29_rx () from /usr/local/lib/libspandsp.so.0 #5 0x2820286c in fax_rx_process () from /usr/...

Hi, Warren, Thanks for writing all of this up. In short, regarding your suggested solution: > 4. To fix this, I think that additional fast-math-flags are likely > needed in > > the IR. Instead of the following set: > > 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > > something like this: > > 'reassoc' + 'libm' + 'nnan' + 'ninf' + '...

> > The other thing that might work, is having TargetMachine remember how > > the fast-isel option got set, and make OptLevelChanger do the right > > thing. But that seems like a hack to work around Mips not obeying the > > specified optimization level, honestly. > > I think we should do that as well. I don't think it's right that optnone > enables Fast...

...be documented. >> > > I think it does make sense to expand them to be more readable. Also, the textual representation doesn't have to precisely follow the internal names. What about: > nnan : no nans > ninf : no infs > nsz : no signed zeros > ar: allow reciprocal > fast : unsafe algebra (and implicitly all the others) These seem reasonable to me. Thanks! Evan > > I'll get started on documentation. > >> Evan >> >> On Nov 15, 2012, at 10:17 AM, Michael Ilseman <milseman at apple.com> wrote: >> >>> Attached a...