search for: michaeljclark

...ing that the actual instruction selection would be reasonably safe. FWIW, FPToUI is not one of the parts my pending patch addresses. -Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Flamedoge via llvm-dev Sent: Wednesday, April 19, 2017 10:14 AM To: Michael Clark <michaeljclark at mac.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long > Are we better off using branches instead of cmove to implement FP to unsigned i64? This seems like it was done for pe...

...that we shouldn’t sacrifice performance just to maintain FP status bits, you’ve got me warming up to the idea that maybe an FP status safe implementation of this might be faster in most cases. It’s at least worth taking some measurements to see if it is faster. -Andy From: Michael Clark [mailto:michaeljclark at mac.com] Sent: Thursday, April 20, 2017 4:02 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: Flamedoge <code.kchoi at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned l...

Changing the list from cfe-dev to llvm-dev > On 20 Apr 2017, at 4:52 AM, Michael Clark <michaeljclark at mac.com> wrote: > > I’m getting close. I think it may be an issue with an individual intrinsic. I’m looking for the X86 lowering of Instruction::FPToUI. > > I found a comment around the rationale for using a conditional move versus a branch. I believe the predicate logic using a...

...s in its build system. BTW I now have some quite non-trivial programs compiling against musl-xnu + libcxx + libcxxabi on macos. There are a lot of libcxx changes like this: -#ifdef __APPLE__ +#if defined(__APPLE__) && !defined(_LIBCPP_HAS_MUSL_LIBC) Michael. [1] https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99 <https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170607/8f9e24e3/attachment.html>

...s.google.com/ > forum/#!topic/llvm-dev/Tl9SD-edUJI > > > > -Andy > > > > > > *From:* Sanjay Patel [mailto:spatel at rotateright.com] > *Sent:* Thursday, May 11, 2017 2:06 PM > *To:* Kaylor, Andrew <andrew.kaylor at intel.com> > *Cc:* Michael Clark <michaeljclark at mac.com>; llvm-dev < > llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] FENV_ACCESS and floating point LibFunc calls > > > > Sounds like the select lowering issue is definitely separate from the FENV > work. > > Is there a bug report with a C or IR exam...

...i on macos. >>> >>> There are a lot of libcxx changes like this: >>> >>> -#ifdef __APPLE__ >>> +#if defined(__APPLE__) && !defined(_LIBCPP_HAS_MUSL_LIBC) >>> >>> Michael. >>> >>> [1] https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99 <https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99>_______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> htt...

...gether a patch, but I’m still learning my way around the ISel code > myself. I think I know enough to figure out what to do but not enough to > tell someone else how to do it without a bunch of wrong turns. > > > > -Andy > > > > > > *From:* Michael Clark [mailto:michaeljclark at mac.com] > *Sent:* Wednesday, May 10, 2017 7:59 PM > *To:* Kaylor, Andrew <andrew.kaylor at intel.com> > *Cc:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* FENV_ACCESS and floating point LibFunc calls > > > > Hi Andy, > > > > I’m interested t...

...uite non-trivial programs compiling against musl-xnu + libcxx + libcxxabi on macos. > > There are a lot of libcxx changes like this: > > -#ifdef __APPLE__ > +#if defined(__APPLE__) && !defined(_LIBCPP_HAS_MUSL_LIBC) > > Michael. > > [1] https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99 <https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99>_______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ------------...

...us as to pointers to primordial branches with whatever needs to be > resurrected. I couldn’t find any Mach-O cmake flags to enable its build. A > pointer to a branch or tag that might have a working Mach-O LLD would be a > start. > > > On 7 Jun 2017, at 11:38 AM, Michael Clark <michaeljclark at mac.com> wrote: > > Hi Rui, > > The motivation would be primarily that LLVM/Clang/LLD are community > projects such that if I or someone in the community added support for e.g. > symbol aliases, then it could be reviewed and potentially merged. ld64 on > the other hand do...

Hi Folks, I have a question regarding LLD support for ld64 mach-o linker synthesised symbols. I did a quick search of the LLD source and I can not find support for them so before I start trying to use lld I thought I would ask. I have found a couple of cases where they are essential. i.e. where there is no other way to get the required information, such as getting the address of the mach-o

Hi Rui, The motivation would be primarily that LLVM/Clang/LLD are community projects such that if I or someone in the community added support for e.g. symbol aliases, then it could be reviewed and potentially merged. ld64 on the other hand does not have a community process for patch submission and code review that I am aware of so its unlikely that if someone from the community came up with a

Hi Andy, I’m interested to try out your patches… I understand the scope of FENV_ACCESS is relatively wide, however I’m still curious if you managed to figure out how to prevent the SelectionDAGLegalize::ExpandNode() FP_TO_UINT lowering of the FPToUI intrinsic from producing the predicate logic that incorrectly sets the floating point accrued exceptions due to unconditional execution of the

On 11 May 2017 at 18:30, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I note that on your bug that you have stated that the branch is faster than > the conditional move. Faster code is a side effect of the fix in this > particular case. On the contrary: the faster code is pretty much the only reason this can happen before the rest of the FENV support lands.