aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/X86/X86FloatingPoint.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-05-23[NFC][CodeGen] Adopt MachineFunctionProperties convenience accessors (#141101)Rahul Joshi1-2/+1
2025-03-15[X86] Use Register and MCRegister. NFCCraig Topper1-2/+2
2024-12-11Reapply "DiagnosticInfo: Clean up usage of DiagnosticInfoInlineAsm" ↵Matt Arsenault1-4/+5
(#119575) (#119634) This reverts commit 40986feda8b1437ed475b144d5b9a208b008782a. Reapply with fix to prevent temporary Twine from going out of scope.
2024-12-11Revert "DiagnosticInfo: Clean up usage of DiagnosticInfoInlineAsm" (#119575)Vitaly Buka1-5/+4
Reverts llvm/llvm-project#119485 Breaks builders, details in llvm/llvm-project#119485
2024-12-11DiagnosticInfo: Clean up usage of DiagnosticInfoInlineAsm (#119485)Matt Arsenault1-4/+5
Currently LLVMContext::emitError emits any error as an "inline asm" error which does not make any sense. InlineAsm appears to be special, in that it uses a "LocCookie" from srcloc metadata, which looks like a parallel mechanism to ordinary source line locations. This meant that other types of failures had degraded source information reported when available. Introduce some new generic error types, and only use inline asm in the appropriate contexts. The DiagnosticInfo types are still a bit of a mess, and I'm not sure why DiagnosticInfoWithLocationBase exists instead of just having an optional DiagnosticLocation in the base class. DK_Generic is for any error that derives from an IR level instruction, and thus can pull debug locations directly from it. DK_GenericWithLoc is functionally the generic codegen error, since it does not depend on the IR and instead can construct a DiagnosticLocation from the MI debug location.
2024-11-22[CodeGen][NewPM] Port EdgeBundles analysis to NPM (#116616)Akshat Oke1-3/+3
2024-08-29[ExtendLifetimes] Implement llvm.fake.use to extend variable lifetimes (#86149)Stephen Tozer1-0/+32
This patch is part of a set of patches that add an `-fextend-lifetimes` flag to clang, which extends the lifetimes of local variables and parameters for improved debuggability. In addition to that flag, the patch series adds a pragma to selectively disable `-fextend-lifetimes`, and an `-fextend-this-ptr` flag which functions as `-fextend-lifetimes` for this pointers only. All changes and tests in these patches were written by Wolfgang Pieb (@wolfy1961), while Stephen Tozer (@SLTozer) has handled review and merging. The extend lifetimes flag is intended to eventually be set on by `-Og`, as discussed in the RFC here: https://discourse.llvm.org/t/rfc-redefine-og-o1-and-add-a-new-level-of-og/72850 This patch implements a new intrinsic instruction in LLVM, `llvm.fake.use` in IR and `FAKE_USE` in MIR, that takes a single operand and has no effect other than "using" its operand, to ensure that its operand remains live until after the fake use. This patch does not emit fake uses anywhere; the next patch in this sequence causes them to be emitted from the clang frontend, such that for each variable (or this) a fake.use operand is inserted at the end of that variable's scope, using that variable's value. This patch covers everything post-frontend, which is largely just the basic plumbing for a new intrinsic/instruction, along with a few steps to preserve the fake uses through optimizations (such as moving them ahead of a tail call or translating them through SROA). Co-authored-by: Stephen Tozer <stephen.tozer@sony.com>
2024-04-24[CodeGen] Make the parameter TRI required in some functions. (#85968)Xu Zhang1-13/+15
Fixes #82659 There are some functions, such as `findRegisterDefOperandIdx` and `findRegisterDefOperand`, that have too many default parameters. As a result, we have encountered some issues due to the lack of TRI parameters, as shown in issue #82411. Following @RKSimon 's suggestion, this patch refactors 9 functions, including `{reads, kills, defines, modifies}Register`, `registerDefIsDead`, and `findRegister{UseOperandIdx, UseOperand, DefOperandIdx, DefOperand}`, adjusting the order of the TRI parameter and making it required. In addition, all the places that call these functions have also been updated correctly to ensure no additional impact. After this, the caller of these functions should explicitly know whether to pass the `TargetRegisterInfo` or just a `nullptr`.
2024-03-08Reapply "Convert many LivePhysRegs uses to LiveRegUnits" (#84338)AtariDreams1-4/+4
This only converts the instances where all that is needed is to change the variable type name. Basically, anything that involves a function that LiveRegUnits does not directly have was skipped to play it safe. Reverts https://github.com/llvm/llvm-project/commit/7a0e222a17058a311b69153d0b6f1b4459414778
2024-03-07Revert "Convert many LivePhysRegs uses to LiveRegUnits (#83905)"Jay Foad1-4/+4
This reverts commit 2a13422b8bcee449405e3ebff957b4020805f91c. It was causing test failures on the expensive check builders.
2024-03-06Convert many LivePhysRegs uses to LiveRegUnits (#83905)AtariDreams1-4/+4
2023-12-24[X86] Use range-based for loops (NFC)Kazu Hirata1-2/+1
2023-11-11[llvm] Stop including llvm/ADT/SmallPtrSet.h (NFC)Kazu Hirata1-1/+0
Identified with clangd.
2023-09-11[InlineAsm] refactor InlineAsm class NFC (#65649)Nick Desaulniers1-3/+4
I would like to steal one of these bits to denote whether a kind may be spilled by the register allocator or not, but I'm afraid to touch of any this code using bitwise operands. Make flags a first class type using bitfields, rather than launder data around via `unsigned`.
2023-08-31[InlineAsm] wrap Kind in enum class NFCNick Desaulniers1-4/+4
Should add some minor type safety to the use of this information, since there's quite a bit of metadata being laundered through an `unsigned`. I'm looking to potentially add more bitfields to that `unsigned`, but I find InlineAsm's big ol' bag of enum values and usage of `unsigned` confusing, type-unsafe, and un-ergonomic. These can probably be better abstracted. I think the lack of static_cast outside of InlineAsm indicates the prior code smell fixed here. Reviewed By: qcolombet Differential Revision: https://reviews.llvm.org/D159242
2023-01-28[Target] Use llvm::count{l,r}_{zero,one} (NFC)Kazu Hirata1-9/+9
2023-01-22Use llvm::popcount instead of llvm::countPopulation(NFC)Kazu Hirata1-1/+1
2022-06-18[X86] Use default member initialization (NFC)Kazu Hirata1-3/+3
Identified with modernize-use-default-member-init.
2022-03-16[NFC][CodeGen] Rename some functions in MachineInstr.h and remove duplicated ↵Shengchen Kan1-10/+10
comments
2021-12-08[NFC] Rename MachineFunction::deleteMachineInstr (coding style)Mircea Trofin1-1/+1
2021-11-25[llvm] Use range-based for loops (NFC)Kazu Hirata1-5/+2
2021-11-12[X86] Preserve FPSW when popping x87 stackSerge Pavlov1-0/+26
When compiler converts x87 operations to stack model, it may insert instructions that pop top stack element. To do it the compiler inserts instruction FSTP right after the instruction that calculates value on the stack. It can break the code that uses FPSW set by the last instruction. For example, an instruction FXAM is usually followed by FNSTSW, but FSTP is inserted after FXAM. As FSTP leaves condition code in FPSW undefined, the compiler produces incorrect code. With this change FSTP in inserted after the FPSW consumer if the last instruction sets FPSW. Differential Revision: https://reviews.llvm.org/D113335
2021-11-06[Target] Use llvm::reverse (NFC)Kazu Hirata1-5/+3
2021-08-24[DebugInfo][InstrRef] Fix over-droppage of locations in X86FloatingPointJeremy Morse1-3/+4
Over in D105657, we started dropping instruction numbers (that become variable locations) from call instructions, as we can't correctly represent the x87 FP stack. Unfortunately, it turns out that the "special FP instructions" that this pass transforms includes "every call instruction" [0]. Thus, we've ended up dropping all return values from all calls. Ouch. This patch adds a filter: only drop instruction numbers from calls if they return something on the FP stack. Seeing how LLVM only allows a single return value, this should drop instruction numbers on anything that returns a float, and nothing else. Rather than writing a new test, I've modified the original one to have a positive and negative case: drop instruction number on a call with an FP-stack modification, keep it on a plain call. Differential Revision: https://reviews.llvm.org/D108580
2021-07-19[InstrRef][X86] Drop debug instruction numbers from x87 instructionsJeremy Morse1-0/+12
Avoid a crash when using instruction referencing if x87 floating point instructions are used. These instructions are significantly mutated when they're rewritten from referring to registers, to referring to floating-point-stack positions. As a result, their operands are re-ordered, and (InstrRef) LiveDebugValues asserts when it sees a DBG_INSTR_REF referring to a non-reg non-def register operand. To fix this, drop the instruction numbers, and thus variable locations. This patch adds a helper utility do do that. Dropping the variable locations is sub-optimal, but applying DBG_VALUEs to the $fp0 and similar registers is dropped on emission too. It seems we've never done well at describing variables that live in x87 registers, at all. Differential Revision: https://reviews.llvm.org/D105657
2021-07-12[X86] Teach X86FloatingPoint's handleCall to only erase the FP stack if ↵Craig Topper1-0/+24
there is a regmask operand that clobbers the FP stack. There are some calls to functions like `__alloca` that are missing a regmask operand. Lack of a regmask operand means that all registers that aren't mentioned by def operands are preserved. __alloca only updates EAX and ESP and has def operands for them so this is ok. Because there is no regmask the register allocator won't spill the FP registers across the call. Assuming we want to keep the FP stack untoched across these calls, we need to handle this is in the FP stackifier. We might want to add a proper regmask operand to the code that creates these calls to indicate all registers are preserved, but we'd still need this change to the FP stackifier to know to preserve the FP stack for such a regmask. The test is kind of long, but bugpoint wasn't able to reduce it any further. Fixes PR50782 Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D105762
2021-06-25[X86] Add description of FXAM instructionSerge Pavlov1-0/+3
Previously this instruction could be used only in assembler. This change makes it available for compiler also. Scheduling information was copied from FTST instruction, hopefully this can be a satisfactory approximation. Differential Revision: https://reviews.llvm.org/D104853
2021-06-01[various] Remove or use variables which are unused but set.Michael Benfield1-3/+1
This is in preparation for the -Wunused-but-set-variable warning. Differential Revision: https://reviews.llvm.org/D102942
2021-05-15[X86] Try to pass DebugLoc by const-ref to avoid costly TrackingMDNodeRef ↵Simon Pilgrim1-1/+1
copies (REAPPLIED). NFCI. Reapply rG5ed56a821c06 (after reverted by rG7aa89c4a22fd) - don't take reference from struct that will be erased in X86FrameLowering::eliminateCallFramePseudoInstr
2021-05-14Revert "[X86] Try to pass DebugLoc by const-ref to avoid costly ↵Mitch Phillips1-1/+1
TrackingMDNodeRef copies. NFCI." This reverts commit 5ed56a821c0622869739a3ae752eea97a1ee1f48. Reason: Broke the MSan buildbots. See Phabricator for more info (https://reviews.llvm.org/rG5ed56a821c0622869739a3ae752eea97a1ee1f48).
2021-05-14[X86] Try to pass DebugLoc by const-ref to avoid costly TrackingMDNodeRef ↵Simon Pilgrim1-1/+1
copies. NFCI.
2021-01-27[llvm] Use llvm::is_sorted (NFC)Kazu Hirata1-1/+1
2020-01-16Insert wait instruction after X87 instructions which could raiseLiu, Chen31-0/+3
float-point exception. This patch also modify some mayRaiseFPException flag which set in D68854. Differential Revision: https://reviews.llvm.org/D72750
2020-01-02X86: remove unused variableSaleem Abdulrasool1-1/+0
Remove the now unused-variable from aa17d31edb00c66461093b5a7cd2f4a35dc143e9. This breaks `-Werror` builds.
2020-01-02[X86] Remove FP0-6 operands from call instructions in FPStackifier pass. ↵Craig Topper1-9/+11
Only count defs as returns. All FP0-6 operands should be removed by the FP stackifier. By removing these we fix the machine verifier error in PR39437. I've also made it so that only defs are counted for STReturns which removes what I think were extra stack cleanup instructions. And I've removed the regcall assert because it was checking the attributes of the caller, but here we're concerned with the attributes of the callee. But I don't know how to get that information from this level.
2019-12-11[FPEnv][X86] Constrained FCmp intrinsics enabling on X86Wang, Pengfei1-1/+11
Summary: This is a follow up of D69281, it enables the X86 backend support for the FP comparision. Reviewers: uweigand, kpn, craig.topper, RKSimon, cameron.mcinally, andrew.w.kaylor Subscribers: hiraditya, llvm-commits, annita.zhang, LuoYuanke, LiuChen3 Tags: #llvm Differential Revision: https://reviews.llvm.org/D70582
2019-11-13Sink all InitializePasses.h includesReid Kleckner1-0/+1
This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
2019-11-06[X86] Fix uninitialized variable warnings. NFCI.Simon Pilgrim1-4/+4
2019-10-31[X86] Remove FSIN/FCOS isel patterns and the pseudo instructions that they ↵Craig Topper1-6/+0
selected for the FP stackifier. We always expand these to libcalls so get rid of the last vestiges of using the instructions.
2019-08-15Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders1-3/+3
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Partial reverts in: X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned& MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register PPCFastISel.cpp - No Register::operator-=() PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned& MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor Manual fixups in: ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned& HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register. PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned& Depends on D65919 Reviewers: arsenm, bogner, craig.topper, RKSimon Reviewed By: arsenm Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65962 llvm-svn: 369041
2019-06-21Simplify std::lower_bound with llvm::{bsearch,lower_bound}. NFCFangrui Song1-1/+1
llvm-svn: 364006
2019-06-13X86: Clean up pass initializationTom Stellard1-2/+8
Summary: - Remove redundant initializations from pass constructors that were already being initialized by LLVMInitializeX86Target(). - Add initialization function for the FPS pass. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63218 llvm-svn: 363221
2019-02-08Implementation of asm-goto support in LLVMCraig Topper1-1/+2
This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
2019-02-04[X86] Add ST0 as an implicit def/use of x87 load/store instructions during ↵Craig Topper1-0/+4
FP stackifying. These instructions implicitly operate on ST0, but we don't currently add that information to the MachineInstr. We also don't add it the tablegen definitions either. For the most part this doesn't cause any problems because the stackifying occurs after register allocation. All the instructions are marked as having side effects so the postRA scheduler won't reorder them amongst themselves. But nothing stops inline assembly using X87 instructions from being reordered around other x87 instructions if that inline assembly wasn't marked volatile. The two test cases I've identified so far in PR40539 involve loads and stores used to set up the inline assembly or capture the results of the inline assembly ending up in the wrong order. This patch adds implicit ST0 uses/defs to the load/store instructions to prevent this from happening. I plan to fix all of the FP instructions, but the binops are bit trickier to get right. So I've chosen fixing the known test cases as a good first step. I think we also need to update the tablegen descriptions so MS inline assembly infers the right clobbers, but I haven't checked that yet. Differential Revision: https://reviews.llvm.org/D57644 llvm-svn: 353070
2019-01-30[X86] Remove unnecessary code from the top of handleCompareFP in ↵Craig Topper1-2/+0
X86FloatingPoint.cpp. There were checks to ensure some tables were sorted, but those tables aren't used by this function. The same tables are checked in the function that does use them. Maybe this was copy/pasted? llvm-svn: 352609
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-07-30Remove trailing spaceFangrui Song1-3/+3
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
2018-05-14Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen1-26/+31
The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
2018-05-09[DebugInfo] Examine all uses of isDebugValue() for debug instructions.Shiva Chen1-1/+1
Because we create a new kind of debug instruction, DBG_LABEL, we need to check all passes which use isDebugValue() to check MachineInstr is debug instruction or not. When expelling debug instructions, we should expel both DBG_VALUE and DBG_LABEL. So, I create a new function, isDebugInstr(), in MachineInstr to check whether the MachineInstr is debug instruction or not. This patch has no new test case. I have run regression test and there is no difference in regression test. Differential Revision: https://reviews.llvm.org/D45342 Patch by Hsiangkai Wang. llvm-svn: 331844
2018-04-30IWYU for llvm-config.h in llvm, additions.Nico Weber1-0/+1
See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
generated by cgit v1.1 at 2025-08-03 19:37:39 +0000