similar to: May IR types be merged by llvm-link?

On 10/03, Kaylor, Andrew via llvm-dev wrote: > I’d like to emphasize that the constrained intrinsics prevent > optimizations *by default*. We have a plan to go back and teach > individual optimizations how to handle these intrinsics. The idea is > that if an optimization knows nothing about the constrained intrinsics > then it won’t try to transform them, but if an optimization has

On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <hfinkel at anl.gov> wrote: > Andy, thanks for writing this up. A few thoughts: > > 1. The mental model that I have is that there is always an FP_CONTRACT pragma: there's some default (implicit) pragma at the beginning, and what it says (off/on/fast) is controlled by the command-line flags (or the driver's default if no flags

Which optimization did you find unsafe? Thanks, --Serge ср, 21 авг. 2019 г. в 05:12, Cameron McInally <cameron.mcinally at nyu.edu>: > On Tue, Aug 20, 2019 at 1:02 PM Serge Pavlov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> During the review of https://reviews.llvm.org/D65997 >>

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

> > I'm not sure why this is an issue. Yes, these two intrinsics depend > on the current rounding mode according to the C standard, and yes, > LLVM in default mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. Any other intrinsic, like `floor`,

Hi everyone, According to the current design an intrinsic call that depends on current floating point environment (for example, rounding mode) or change it (for example by raising FP exceptions) is represented by constrained intrinsics. The latter have attached metadata that provide info about current FP environment and have attribute `IntrInaccessibleMemOnly` that helps keeping order of

> > One concern with replacing llvm.rint and llvm.nearbyint with > llvm.roundeven makes it difficult to turn back into a libcall if the > backend doesn't have an instruction for it. You can't just call the > roundeven library function since that wouldn't exist in older libm > implementations. So ideally you would know which function was originally > used in the

Hi all, During the review of https://reviews.llvm.org/D65997 an issue was revealed, which relates to the decision of how compiler should represents constrained floating point operations. If a floating point operation requires rounding mode or exception behavior different from the default, it should be represented by constrained intrinsic (

Hi Renato, Thank you very much for the directions, I am going to recommit my fix. What are hardware used in buildbots? Are these common boards like PandaBoard or some thing special? What is RAM installed? Thanks, --Serge 2014-12-11 2:36 GMT+06:00 Renato Golin <renato.golin at linaro.org>: > On 10 December 2014 at 19:06, Serge Pavlov <sepavloff at gmail.com> wrote: > > In

> > The only issue I see is that since we also assume FP operations have no > side effects by default there is no difference between llvm.rint and > llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint > completely. The forthcoming C standard ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8) defines new function, `roundeven`, which implements

Some clarification after getting feedback from Craig Topper…. It’s probably best to say in the documentation that the llvm.nearbyint and llvm.rint functions “assume the default rounding mode, roundToNearest”. This will allow the optimizer to transform them as if they were rounding to nearest without requiring backends to use an encoding that enforces roundToNearest as the rounding mode for these

Hi all, In revision 223114 I committed a fix to clang project. It caused fail on clang-native-arm-cortex-a9: http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/23599. According to logs it was a problem with memory allocated by malloc. Reverting the fix in 223120 made the bot green. The changed code does nothing with heap, none of other bots failed, so it looks like a platform

Files '.arcconfig' still contain reference to http://llvm-reviews.chandlerc.com/, so arcanist doesn't work. Thanks, --Serge 2014-04-06 3:11 GMT+07:00 Manuel Klimek <klimek at google.com>: > On Sat, Apr 5, 2014 at 8:42 PM, Manuel Klimek <klimek at google.com> wrote: > >> Short update - the sending to the *-commits lists doesn't work yet - I'm >>

This is a feature (or bug) of MCSectionELF::PrintSwitchToSection. For ELF target this function tries to escape string if it founds 'suspicious' character, see implementation in MCSectionELF.cpp: StringRef name = getSectionName(); if (name.find_first_not_of("0123456789_." "abcdefghijklmnopqrstuvwxyz"

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

+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

Seems there were a couple of correlated failures that appear to be flakes on this buildbot recently: green: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/13974 red: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/13975 (target-override.c during stage 1, seems to be missing the directory/symlink it just created) red:

Well, I am at my wit's end. I have copied over the script and directories for this test case and run it a few million times. First I was running one at a time, then I switched to kicking off 1000 at a time. All the while, the bots continued to run on the same machine. The script never failed even once. I am not sure if this has something to do with Python as part of llvm-lit or what is going

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

On 10/2/19 5:12 PM, Hal Finkel wrote: On 10/1/19 12:35 AM, Serge Pavlov via llvm-dev wrote: 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