Displaying 9 results from an estimated 9 matches for "ffloor".
Did you mean:
floor
2017 Nov 04
2
RFC: We need to explicitly state that some functions are reserved by LLVM
...39;s not reasonable
>> for the frontend to know about every function the optimizer knows about.
>> Over-marking seems okay, however.
>
> I think this is the pragmatic way forwards. For a concise example of
> how broken/surprising the current behaviour is:
> <snip>
> ffloor is legal for AArch64, meaning frintm is produced rather than a
> call to floor. Deleting the 'readnone' attribute from the floor
> function will avoid lowering to ffloor. Compile with -mtriple=arm and
> the generated assembly has completely different semantics (calling
> floor a...
2012 Jul 26
0
[LLVMdev] [llvm-commits] [llvm] r160791 - in /llvm/trunk: docs/LangRef.html include/llvm/Intrinsics.td lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
...l.espindola at gmail.com> wrote:
>> +<p>This function returns the same values as the libm <tt>floor</tt> functions
>> + would, and handles error conditions in the same way.</p>
>
> Why the intrinsic then?
So that it's possible to access the ISD::FFLOOR SDNode without having to enable a C-specific TargetLibraryInfo's.
--Owen
2017 Oct 27
5
RFC: We need to explicitly state that some functions are reserved by LLVM
On Fri, Oct 27, 2017 at 1:50 AM, David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> This seems slightly inverted. As I understand it, the root of the problem
> is that some standards, such as C, C++, and POSIX, define some functions as
> special and we rely on their specialness when optimising. Unfortunately,
> the specialness is a property of the source
2017 Nov 11
5
RFC: We need to explicitly state that some functions are reserved by LLVM
...v at lists.llvm.org> wrote:
>
> On Nov 4, 2017, at 3:12 PM, Alex Bradbury via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I think this is the pragmatic way forwards. For a concise example of
> how broken/surprising the current behaviour is:
> <snip>
> ffloor is legal for AArch64, meaning frintm is produced rather than a
> call to floor. Deleting the 'readnone' attribute from the floor
> function will avoid lowering to ffloor. Compile with -mtriple=arm and
> the generated assembly has completely different semantics (calling
> floor a...
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...case ISD::FSIN:
+ case ISD::FCOS:
+ case ISD::FPOWI:
+ case ISD::FPOW:
+ case ISD::FLOG:
+ case ISD::FLOG2:
+ case ISD::FLOG10:
+ case ISD::FEXP:
+ case ISD::FEXP2:
+ case ISD::FCEIL:
+ case ISD::FTRUNC:
+ case ISD::FRINT:
+ case ISD::FNEARBYINT:
+ case ISD::FFLOOR:
+ switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) {
+ case TargetLowering::Promote:
+ Result = PromoteVectorOp(SDValue(Result, 0)).getNode();
+ break;
+ case TargetLowering::Legal: break;
+ case TargetLowering::Custom: {
+ SDValue...
2009 May 20
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...case ISD::FSIN:
+ case ISD::FCOS:
+ case ISD::FPOWI:
+ case ISD::FPOW:
+ case ISD::FLOG:
+ case ISD::FLOG2:
+ case ISD::FLOG10:
+ case ISD::FEXP:
+ case ISD::FEXP2:
+ case ISD::FCEIL:
+ case ISD::FTRUNC:
+ case ISD::FRINT:
+ case ISD::FNEARBYINT:
+ case ISD::FFLOOR:
+ switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) {
+ case TargetLowering::Promote:
+ Result = PromoteVectorOp(SDValue(Result, 0)).getNode();
+ break;
+ case TargetLowering::Legal: break;
+ case TargetLowering::Custom: {
+ SDValue...
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote:
> Can you explain why you chose the approach of using a new pass?
> I pictured removing LegalizeDAG's type legalization code would
> mostly consist of finding all the places that use TLI.getTypeAction
> and just deleting code for handling its Expand and Promote. Are you
> anticipating something more
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 1:34 PM, Eli Friedman wrote:
> On Wed, May 20, 2009 at 1:19 PM, Eli Friedman
> <eli.friedman at gmail.com> wrote:
>
>> Per subject, this patch adding an additional pass to handle vector
>>
>> operations; the idea is that this allows removing the code from
>>
>> LegalizeDAG that handles illegal types, which should be a significant
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...case ISD::FSIN:
+ case ISD::FCOS:
+ case ISD::FPOWI:
+ case ISD::FPOW:
+ case ISD::FLOG:
+ case ISD::FLOG2:
+ case ISD::FLOG10:
+ case ISD::FEXP:
+ case ISD::FEXP2:
+ case ISD::FCEIL:
+ case ISD::FTRUNC:
+ case ISD::FRINT:
+ case ISD::FNEARBYINT:
+ case ISD::FFLOOR:
+ switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) {
+ case TargetLowering::Promote:
+ Result = PromoteVectorOp(SDValue(Result, 0)).getNode();
+ break;
+ case TargetLowering::Legal: break;
+ case TargetLowering::Custom: {
+ SDValue...