This is mere refactoring of the code and is not linked to any

specific issue.

I think ARM's DivU64x32() would be better located along MultU64x32()
and other calls in ARM's math.c, as having it in a header seems weird,
even with the goal of inlining it. I doubt there's much performance
to be lost from having it non-inline in math.c and it should make the
code breakdown more logical.

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>

1 files changed, 0 insertions, 14 deletions

diff --git a/inc/arm/efibind.h b/inc/arm/efibind.h
index 0978079..06f6ea1 100644
--- a/inc/arm/efibind.h
+++ b/inc/arm/efibind.h
@@ -162,17 +162,3 @@ typedef uint32_t   UINTN;
 
 #define uefi_call_wrapper(func, va_num, ...) func(__VA_ARGS__)
 #define EFI_FUNCTION
-
-static inline UINT64 DivU64x32(UINT64 Dividend, UINTN Divisor, UINTN *Remainder)
-{
-    /*
-     * GCC turns a division into a multiplication and shift with precalculated
-     * constants if the divisor is constant and the dividend fits into a 32 bit
-     * variable. Otherwise, it will turn this into calls into the 32-bit div
-     * library functions.
-     */
-    if (Remainder)
-        *Remainder = Dividend % Divisor;
-    Dividend = Dividend / Divisor;
-    return Dividend;
-}