similar to: EuroLLVM "Round Table" topics

On 04/12/2018 01:40 AM, p23 power via llvm-dev wrote: > Hi, > We are looking for new "Round Table" topics (i.e. mini-bof topics - > formally known as hackers lab).  The round table sessions are a great > way for us all to discuss face-to-face any burning topics. We have > scheduled a table after each BoF sessions so that people can follow up > on those

Hello, at the recent EuroLLVM developer meeting in Bristol I held a BoF session on the topic "Towards implementing #pragma STDC FENV_ACCESS". I've also had a number of follow-on discussions both on-site in Bristol and online since. This post is intended as a summary of my current understanding set of requirements and implementation details covering the overall topic. I'm

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog

Hi Ulrich, I am interested in knowing if the current proposals also take into account the FP_CONTRACT pragma and the ability to implement options that imply a specific value for the FLT_EVAL_METHOD macro. Additionally, I am not aware of the IR being able to represent the potentially deferred loss of precision that the C language semantics provide; in particular, applying such semantics to the

On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > Hi Ulrich, > > I am interested in knowing if the current proposals also take into > account the FP_CONTRACT pragma We should already do this (we turn relevant operations into the @llvm.fmuladd. when FP_CONTRACT is set to on during IR generation). > and the ability to implement options that imply a specific value for >

+cfe-dev as the discussion is now biased toward C standard. I'm not sure what problem you see here. In default mode, i.e. > when there is no "#pragma STDC FENV_ACCESS on" in effect, > then the compiler can always assume that the default rounding > mode is in effect. Well, if #pragma STDC FENV_ACCESS on is not in effect, that means > that the user has promised that at

On Wed, May 23, 2018 at 12:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > > Hi Ulrich, > > I am interested in knowing if the current proposals also take into account > the FP_CONTRACT pragma > > > We should already do this (we turn relevant operations into the > @llvm.fmuladd. when FP_CONTRACT is

Copying the list on a discussion of potentially general interest.... From: Kaylor, Andrew Sent: Friday, November 03, 2017 1:11 PM To: 'Ding, Wei' <Wei.Ding2 at amd.com>; Sumner, Brian <Brian.Sumner at amd.com>; Arsenault, Matthew <Matthew.Arsenault at amd.com> Subject: RE: clarification needed for the constrained fp implementation. Hi Wei, I've been meaning to

On 11/03/2017 05:26 PM, 陳韋任 via llvm-dev wrote: > > > 2017-11-04 4:29 GMT+08:00 Kaylor, Andrew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: > > Copying the list on a discussion of potentially general interest…. > > *From:* Kaylor, Andrew > *Sent:* Friday, November 03, 2017 1:11 PM > *To:* 'Ding,

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set

Hi all, This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND' as well as some other related facilities. Problem On many processors use of non-default floating mode requires

Andrew Kaylor wrote: >In general, the current "strict FP" handling stops at instruction >selection. At the MachineIR level we don't currently have a mechanism >to prevent inappropriate optimizations based on floating point >constraints, or indeed to convey such constraints to the backend. >Implicit register use modeling may provide some restriction on some

Hey folks, Do we have proposals for an HPC focused BoF at EuroLLVM? I'd like to discuss the current efforts around integrating Polly, parallel IR efforts and vectoriser support in VPlan (like outer loop), as well as coordination on the next steps around Flang. -- cheers, --renato

Yes, you’re probably right about this. I was originally thinking of FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting aligns with what Cameron suggested and even some of my own reasoning on other points. So, let me amend my previous proposal to say: STDC FENV_ACCESS {ON|OFF} Patch in progress. I think ON should force the following: except_behavior { strict }

Hi all, Implementation of #pragma STDC FENV_ACCESS raises a problem: what to do if a function is called inside a region where FP environment differs from the default? If the function expects default FP mode it may work incorrectly in such case. The C2x standard draft ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf) states (7.6p4): Certain programming conventions support the intended

Hello debug-info fans, There has been a lot of activity in the debug-info area lately, and I was wondering if there's interest in a BoF session this April. Alternatively we could just have a hacker-lab table again, which worked out pretty well at the last US meeting. Some potential discussion topics for the BoF/table could be: * Improving debugging of optimized code ** Defining what -Og

On 03/20/2018 05:05 AM, Michael Kruse wrote: > There's none yet according to http://llvm.org/devmtg/2018-04/#talks > > Unfortunately, I won't be present, but IMHO it would be nice to have one. I agree. This seems like a good idea.  -Hal > > Michael > > > > 2018-03-20 7:50 GMT+01:00 Renato Golin <renato.golin at linaro.org>: >> Hey folks, >>

I'm working on the #pragma STDC FENV_ACCESS ON support, specifically the support for a strict version of the FP to unsigned int conversion. I've got a pass that runs and converts a new intrinsic into code that uses the FP to signed int conversion code similar to how SelectionDAG handles this now. Except that SelectionDAG will let the target handle it if the target says it will. How do I,

There's none yet according to http://llvm.org/devmtg/2018-04/#talks Unfortunately, I won't be present, but IMHO it would be nice to have one. Michael 2018-03-20 7:50 GMT+01:00 Renato Golin <renato.golin at linaro.org>: > Hey folks, > > Do we have proposals for an HPC focused BoF at EuroLLVM? > > I'd like to discuss the current efforts around integrating Polly,

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