[docs][LangRef] Added minor update inside the `frem`. Fix : #61653

[aabhinavg]

Summary

Added minor update inside the frem. Fix : #61653

[aabhinavg]

done some minor fix

[RKSimon]

llvm/docs/LangRef.rst

9533

This doesn't seem to match with what you've added above - is x86 setting errno?

[aabhinavg]

llvm/docs/LangRef.rst

9533

the ‘frem’ instruction is commonly used in the implementation of mathematical functions in the standard C library, known as libm. The libm library provides a wide range of mathematical functions, such as trigonometric functions, logarithmic functions, exponential functions, and more.

The implementation of these functions often involves the use of the ‘frem’ instruction to calculate remainders, which are used in various computations. For example, the implementation of the trigonometric function ‘sine’ typically involves computing the remainder of the angle divided by 2π, which can be done using the ‘frem’ instruction.

Overall, the ‘frem’ instruction is a fundamental building block for many mathematical functions in libm and is a crucial part of many numerical computations in general.

‘frem’ instruction itself does not set ‘errno’ on x86 systems, but errors can be detected by checking the result of the instruction or examining the floating-point status flags.

[bchetioui]

Sorry for the delay in replying to this. I don't think that such implementation details belong in the documentation of the operation.
Is there a particular problem that would have been avoided by adding in this information?

[bchetioui]

Thanks!

I understand now that the intent behind the issue is that one may need to link libm in order to use frem, which was not obvious to me from the initial change.
I suggested an edit that conveys this more directly. Let me know what you think.

llvm/docs/LangRef.rst

9517–9520

Thanks for your patience. I propose the following rewrite for your change (or something to that effect). WDYT?

[bchetioui]

llvm/docs/LangRef.rst

9517–9520

Seems like I am missing a linefeed after the last line, please add that too :-)

[aabhinavg]

Done the required fix

[bchetioui]

Thank you, this looks good to me.

llvm/docs/LangRef.rst

.. code-block:: llvm
     !0 = !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
 
 .. _range-metadata:
 
 '``range``' Metadata
 ^^^^^^^^^^^^^^^^^^^^
 
 ``range`` metadata may be attached only to ``load``, ``call`` and ``invoke`` of
-integer or vector of integer types. It expresses the possible ranges the loaded
-value or the value returned by the called function at this call site is in. If
-the loaded or returned value is not in the specified range, a poison value is
-returned instead. The ranges are represented with a flattened list of integers.
-The loaded value or the value returned is known to be in the union of the ranges
+integer types. It expresses the possible ranges the loaded value or the value
+returned by the called function at this call site is in. If the loaded or
+returned value is not in the specified range, a poison value is returned
+instead. The ranges are represented with a flattened list of integers. The
+loaded value or the value returned is known to be in the union of the ranges
 defined by each consecutive pair. Each pair has the following properties:
 
--  The type must match the scalar type of the instruction.
+-  The type must match the type loaded by the instruction.
 -  The pair ``a,b`` represents the range ``[a,b)``.
 -  Both ``a`` and ``b`` are constants.
 -  The range is allowed to wrap.
 -  The range should not represent the full or empty set. That is,
    ``a!=b``.
 
 In addition, the pairs must be in signed order of the lower bound and
 they must be non-contiguous.
 
-For vector-typed instructions, the range is applied element-wise.
-
 Examples:
 
 .. code-block:: llvm
 
       %a = load i8, ptr %x, align 1, !range !0 ; Can only be 0 or 1
       %b = load i8, ptr %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1
       %c = call i8 @foo(),       !range !2 ; Can only be 0, 1, 3, 4 or 5
       %d = invoke i8 @bar() to label %cont
              unwind label %lpad, !range !3 ; Can only be -2, -1, 3, 4 or 5
-      %e = load <2 x i8>, ptr %x, !range 0 ; Can only be <0 or 1, 0 or 1>
     ...
     !0 = !{ i8 0, i8 2 }
     !1 = !{ i8 255, i8 2 }
     !2 = !{ i8 0, i8 2, i8 3, i8 6 }
     !3 = !{ i8 -2, i8 0, i8 3, i8 6 }
 
 '``absolute_symbol``' Metadata
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: text
     define dso_local i32 @f() !kcfi_type !0 {
       ret i32 0
     }
     !0 = !{i32 12345678}
 
 Clang emits ``kcfi_type`` metadata nodes for address-taken functions with
 ``-fsanitize=kcfi``.
 
-.. _md_memprof:
-
-'``memprof``' Metadata
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The ``memprof`` metadata is used to record memory profile data on heap
-allocation calls. Multiple context-sensitive profiles can be represented
-with a single ``memprof`` metadata attachment.
-
-Example:
-
-.. code-block:: text
-
-    %call = call ptr @_Znam(i64 10), !memprof !0, !callsite !5
-    !0 = !{!1, !3}
-    !1 = !{!2, !"cold"}
-    !2 = !{i64 4854880825882961848, i64 1905834578520680781}
-    !3 = !{!4, !"notcold"}
-    !4 = !{i64 4854880825882961848, i64 -6528110295079665978}
-    !5 = !{i64 4854880825882961848}
-
-Each operand in the ``memprof`` metadata attachment describes the profiled
-behavior of memory allocated by the associated allocation for a given context.
-In the above example, there were 2 profiled contexts, one allocating memory
-that was typically cold and one allocating memory that was typically not cold.
-
-The format of the metadata describing a context specific profile (e.g.
-``!1`` and ``!3`` above) requires a first operand that is a metadata node
-describing the context, followed by a list of string metadata tags describing
-the profile behavior (e.g. ``cold`` and ``notcold``) above. The metadata nodes
-describing the context (e.g. ``!2`` and ``!4`` above) are unique ids
-corresponding to callsites, which can be matched to associated IR calls via
-:ref:`callsite metadata<md_callsite>`. In practice these ids are formed via
-a hash of the callsite's debug info, and the associated call may be in a
-different module. The contexts are listed in order from leaf-most call (the
-allocation itself) to the outermost callsite context required for uniquely
-identifying the described profile behavior (note this may not be the top of
-the profiled call stack).
-
-.. _md_callsite:
-
-'``callsite``' Metadata
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The ``callsite`` metadata is used to identify callsites involved in memory
-profile contexts described in :ref:`memprof metadata<md_memprof>`.
-
-It is attached both to the profile allocation calls (see the example in
-:ref:`memprof metadata<md_memprof>`), as well as to other callsites
-in profiled contexts described in heap allocation ``memprof`` metadata.
-
-Example:
-
-.. code-block:: text
-
-    %call = call ptr @_Z1Bb(void), !callsite !0
-    !0 = !{i64 -6528110295079665978, i64 5462047985461644151}
-
-Each operand in the ``callsite`` metadata attachment is a unique id
-corresponding to a callsite (possibly inlined). In practice these ids are
-formed via a hash of the callsite's debug info. If the call was not inlined
-into any callers it will contain a single operand (id). If it was inlined
-it will contain a list of ids, including the ids of the callsites in the
-full inline sequence, in order from the leaf-most call's id to the outermost
-inlined call.
-
 Module Flags Metadata
 =====================
 
 Information about the module as a whole is difficult to convey to LLVM's
 subsystems. The LLVM IR isn't sufficient to transmit this information.
 The ``llvm.module.flags`` named metadata exists in order to facilitate
 this. These flags are in the form of key / value pairs --- much like a
 dictionary --- making it easy for any subsystem who cares about a flag to

 ::
 
       <result> = frem [fast-math flags]* <ty> <op1>, <op2>   ; yields ty:result
 
 Overview:
 """""""""
 
 The '``frem``' instruction returns the remainder from the division of
-its two operands.
+its two operands. On some target, such as X86, the instruction is 
+implemented as call to '``libm``' '``fmod``' function, but the 
+output is equivalent to the mathematical remainder.
 
 Arguments:
 """"""""""
 
 The two arguments to the '``frem``' instruction must be
 :ref:`floating-point <t_floating>` or :ref:`vector <t_vector>` of
 floating-point values. Both arguments must have identical types.
 
 Semantics:
 """"""""""
 
 The value produced is the floating-point remainder of the two operands.
 This is the same output as a libm '``fmod``' function, but without any
 possibility of setting ``errno``. The remainder has the same sign as the
 dividend.
 This instruction is assumed to execute in the default :ref:`floating-point
 environment <floatenv>`.
 This instruction can also take any number of :ref:`fast-math
 flags <fastmath>`, which are optimization hints to enable otherwise
 unsafe floating-point optimizations:
 
 Example: