search for: 596610

...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 easily imagi...

...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 easily imagi...

...t; 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, but s...

...t; 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, but s...

...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 easily imagi...

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

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', 'nsz' and 'arcp'):

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