search for: fastly

Displaying 20 results from an estimated 12582 matches for "fastly".

Did you mean: lastly
2012 Nov 15
3
[LLVMdev] [PATCH] fast-math patches!
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
2004 Jul 12
1
rxfax/spandsp fails to decode
Hi, I just sent this to Steve Underwood, but then found a bunch of posts on the mailing list about similar issues.. does anyone have the fix? I'm running asterisk CVS-HEAD-06/28/04-18:13:13, spandsp 0.0.1k, libtif 3.5.7 one thing i just noticed is that calls come in with format '72' which is G711A-law or LinearPCM.. it uses PCM for the call, i assume this is ok the results
2012 Nov 15
0
[LLVMdev] [llvm-commits] [PATCH] fast-math patches!
Trying to apply patches.. What's your base revision? Joe On Nov 15, 2012, at 5:44 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 > >
2016 Nov 16
3
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
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'):
2016 Nov 16
5
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
----- Original Message ----- > From: "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,
2012 Nov 15
2
[LLVMdev] [llvm-commits] [PATCH] fast-math patches!
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
2016 Nov 16
3
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
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 previous post: > ... > I think these are valuable problems to solve, but you should tackle them piece by piece: > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > 2) the backend is still using
2016 Nov 17
4
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
I don’t really like the idea of updating checks of UnsafeAlgebra() to depend on all of the other flags. It seems like it would be preferable to look at each optimization and figure out which flags it actually requires. I suspect that in many cases the “new” flag (i.e. allowing reassociation, etc.) will be what is actually needed anyway. I would be inclined to agree with Niolai’s suggestion of
2017 Sep 29
2
Trouble when suppressing a portion of fast-math-transformations
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
2012 Nov 15
2
[LLVMdev] [PATCH] fast-math patches!
On Nov 15, 2012, at 10:38 AM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi Michael, > > The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A' seem cryptic to me. Does it make sense to expand them a bit 'nnan', 'inf', etc.? They definitely
2018 Aug 21
4
different output with fast-math flag
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 care about small numbers and
2016 Nov 11
2
initialization-order-fiasco in MCTargetDesc/X86MCAsmInfo.cpp
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
2016 Nov 17
2
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
> On Nov 16, 2016, at 6:22 PM, Ristow, Warren <warren.ristow at sony.com> wrote: > > > ... 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
2012 Nov 15
0
[LLVMdev] [llvm-commits] [PATCH] fast-math patches!
On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: > 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
2012 Nov 16
2
[LLVMdev] [llvm-commits] [PATCH] fast-math patches!
Another round of improved patches, and a patch for documentation changes to LangRef. * Make comments more up to date * Use 'arcp' instead of 'ar' * Use logical || Still based off of r168110 On Nov 15, 2012, at 3:31 PM, Michael Ilseman <milseman at apple.com> wrote: > > On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: >
2017 Sep 29
0
Trouble when suppressing a portion of fast-math-transformations
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' +
2012 Nov 15
2
[LLVMdev] [PATCH] fast-math patches!
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.patch Type:
2004 Apr 28
1
spandsp rxfax crashes *
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
2015 Nov 17
3
Mips unconditionally uses fast-isel?
> > 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
2012 Nov 15
0
[LLVMdev] [PATCH] fast-math patches!
On Nov 15, 2012, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote: > > On Nov 15, 2012, at 10:38 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> Hi Michael, >> >> The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A'