search for: d26708

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

...nsider changing the semantics of > 'fast' flag implying all fast-math-flags > Hi, > > On Nov 15, 2016, at 5:15 PM, Ristow, Warren via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: > > > 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 > &g...

...is the first thing to fix. > 2) the backend is still using the global UnsafeFPMath and it should be killed. I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). Regarding (1), over at https://reviews.llvm.org/D26708#596610, David made the same point that it should be done in Clang. I can understand that, but I wonder whether having the concept of the 'fast' flag in the IR that implies all the other FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easil...

...is the first thing to fix. > 2) the backend is still using the global UnsafeFPMath and it should be killed. I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). Regarding (1), over at https://reviews.llvm.org/D26708#596610, David made the same point that it should be done in Clang. I can understand that, but I wonder whether having the concept of the 'fast' flag in the IR that implies all the other FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easil...

...> > 2) the backend is still using the global UnsafeFPMath and it should be killed. > > I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). > > Regarding (1), over at https://reviews.llvm.org/D26708#596610 <https://reviews.llvm.org/D26708#596610>, David made the same point that it should be done in Clang. I can understand that, but I wonder whether having the concept of the 'fast' flag in the IR that implies all the other FMF makes sense? I'm not seeing a good reason for it...

...> > 2) the backend is still using the global UnsafeFPMath and it should be killed. > > I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). > > Regarding (1), over at https://reviews.llvm.org/D26708#596610 <https://reviews.llvm.org/D26708#596610>, David made the same point that it should be done in Clang. I can understand that, but I wonder whether having the concept of the 'fast' flag in the IR that implies all the other FMF makes sense? I'm not seeing a good reason for it...

...is the first thing to fix. > 2) the backend is still using the global UnsafeFPMath and it should be killed. I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1). Regarding (1), over at https://reviews.llvm.org/D26708#596610, David made the same point that it should be done in Clang. I can understand that, but I wonder whether having the concept of the 'fast' flag in the IR that implies all the other FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easil...

...t; > > > I addressed this point (2) for the reciprocal aspect in the > patch, but of course that wasn't useful without doing > something about (1). > > > > Regarding (1), over > at https://reviews.llvm.org/D26708#596610, David made the > same point that it should be done in Clang. I can > understand that, but I wonder whether having the concept of > the 'fast' flag in the IR that implies all the other FMF > makes sense? I'm not seeing...

...t (2) for the reciprocal aspect in the >>> patch, but of course that wasn't useful without doing >>> something about (1). >>> >>> >>> >>> Regarding (1), over >>> at https://reviews.llvm.org/D26708#596610, David made the >>> same point that it should be done in Clang. I can >>> understand that, but I wonder whether having the concept of >>> the 'fast' flag in the IR that implies all the other FMF >>> makes se...