search for: milseman

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 > > <0002-Fast-math-flags-added-to-FPMathOpe...

...t available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/2e3c515f/attachment-0006.obj> -------------- next part -------------- On Nov 15, 2012, at 10:51 AM, Evan Cheng <evan.cheng at apple.com> wrote: > > 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 f...

...SubclassOptionalData &= ~BitToSet; Otherwise looks good to me. Joe On Nov 15, 2012, at 5:50 PM, Joe Abbey <joe.abbey at gmail.com> wrote: > 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 >> >> <0002-Fast-mat...

On Nov 14, 2012, at 12:47 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > >> I think I missed what problem we're trying to solve here. >> >> I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOption...

...ks good to me. > > Joe > > On Nov 15, 2012, at 5:50 PM, Joe Abbey <joe.abbey at gmail.com> wrote: > >> 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 >>> &g...

...9;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 flags, as discussed in my prior RFC. Patches include infrastructure, API support, textual and bitcode reader/writer support, example optimization, and test cases. >>...

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: > >> Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. >> >> + bool any() { >> + return UnsafeAlg...

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

...tions my inclination would be to skip llvm.fmuladd.* and just form them from a*b+c expressions at isel time. I don't see any fundamental problem with forming llvm.fmuladd.* to model FMA formation opportunities in an IR pass though. - Lang. On Wed, Dec 12, 2012 at 4:11 PM, Michael Ilseman <milseman at apple.com> wrote: > > On Dec 12, 2012, at 3:40 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > > Hi, Dear All: > > I'm going implement FMA formation. On some architectures, "FMA a, b, c" > is more precise than > "a * b + c". I'...

...eam Size: 2928 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121114/12a06609/attachment.obj> -------------- next part -------------- Does this patch make sense, or am I still missing the main concern? On Nov 14, 2012, at 1:39 PM, Michael Ilseman <milseman at apple.com> wrote: > > On Nov 14, 2012, at 12:47 PM, Chris Lattner <clattner at apple.com> wrote: > >> >> On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: >> >>> I think I missed what problem we're trying to s...

...vm.fmuladd.* and just form them from > a*b+c expressions at isel time. I don't see any fundamental problem > with forming llvm.fmuladd.* to model FMA formation opportunities in an > IR pass though. > > - Lang. > > > On Wed, Dec 12, 2012 at 4:11 PM, Michael Ilseman <milseman at apple.com > <mailto:milseman at apple.com>> wrote: > > > On Dec 12, 2012, at 3:40 PM, Shuxin Yang <shuxin.llvm at gmail.com > <mailto:shuxin.llvm at gmail.com>> wrote: > >> Hi, Dear All: >> >> I'm going implement FMA...

On Nov 14, 2012, at 5:13 PM, Michael Ilseman <milseman at apple.com> wrote: > I attached a working patch of changes to the bitcode reader and writer. This patch references other local changes I have to other parts of the code (e.g. "FastMathFlags"), but shows the general idea I'm going for. When I've ironed out all the bugs, I&...

...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 need to be documented. 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 flags, as discussed in my prior RFC. Patches include infrastructure, API support, textual and bitcode reader/writer support, example optimization, and test cases. > > <00...

On Oct 30, 2012, at 4:19 PM, Dan Gohman <dan433584 at gmail.com> wrote: > On Tue, Oct 30, 2012 at 2:25 PM, Michael Ilseman <milseman at apple.com> wrote: > Here's a new version of the RFC, incorporating and addressing the feedback from Krzysztof, Eli, Duncan, and Dan. > > > Revision 1 changes: > * Removed Fusion flag from all sections > * Clarified and changed descriptions of remaining flags: >...

On Tue, Oct 30, 2012 at 2:25 PM, Michael Ilseman <milseman at apple.com> wrote: > Here's a new version of the RFC, incorporating and addressing the feedback > from Krzysztof, Eli, Duncan, and Dan. > > > Revision 1 changes: > * Removed Fusion flag from all sections > * Clarified and changed descriptions of remaining flags: &...

On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > I think I missed what problem we're trying to solve here. > > I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Look...

...LOW_RECIPROCAL)); I found some more in BitcodeReader::ParseConstants(), which I'll scrub after this commits. Will there be a // fmul N 1, x ==> x? perhaps a // fadd N S 0, x ==> x? as well as other arithmetic identities? Cheers, Joe On Nov 15, 2012, at 9:54 PM, Michael Ilseman <milseman at apple.com> wrote: > 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 > > <0001-Fast-math-flag...

...match in fast isel instead of trying to form code? Or are we saying the same thing? (Your words of "fast isel spot"ting and "form better code" caused me to think you mean to do optimizations within the fast isel pass). -eric On Wed, Dec 12, 2012 at 5:14 PM, Michael Ilseman <milseman at apple.com> wrote: > Right now we're shying towards having a re-association helper in > codegen-prepare that will re-associate expressions (if allowed). This would > allow fast-isel to more easily spot FMA opportunities, and form better code. > > On Dec 12, 2012, at 5:11 PM...

Hi Micheal, On Mon, Oct 29, 2012 at 4:34 PM, Michael Ilseman <milseman at apple.com> wrote: > I > Flags > --- > no NaNs (N) > - ignore the existence of NaNs when convenient > no Infs (I) > - ignore the existence of Infs when convenient > no signed zeros (S) > - ignore the existence of negative zero when convenient > Does this m...

Right now we're shying towards having a re-association helper in codegen-prepare that will re-associate expressions (if allowed). This would allow fast-isel to more easily spot FMA opportunities, and form better code. On Dec 12, 2012, at 5:11 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > You hit send right when I did! > For your example, do you mean that