[over.ics.ref]

When a parameter of type “reference to cv T” binds directly ([dcl.init.ref]) to an argument expression:

(1.1)
If the argument expression has a type D that is a derived class of T, the implicit conversion sequence is a derived-to-base conversion from D to T ([over.best.ics]).
(1.2)
Otherwise, if the type of the argument is possibly cv-qualified T, or if T is an array type of unknown bound with element type U and the argument has an array type of known bound whose element type is possibly cv-qualified U, the implicit conversion sequence is the identity conversion.
(1.3)
Otherwise, if T is a function type, the implicit conversion sequence is a function pointer conversion.
(1.4)
Otherwise, the implicit conversion sequence is a qualification conversion.

[Example 1: struct A {}; struct B : public A {} b; int f(A&); int f(B&); int i = f(b); / calls f(B&), an exact match, rather than f(A&), a conversion void g() noexcept; int h(void (&)() noexcept); / #1 int h(void (&)(); / #2 int j = h(g); / calls #1, an exact match, rather than #2, a function pointer conversion — end example]

If the parameter binds directly to the result of applying a conversion function to the argument expression, the implicit conversion sequence is a user-defined conversion sequence ([over.ics.user]) whose second standard conversion sequence is determined by the above rules.

When a parameter of reference type is not bound directly to an argument expression, the conversion sequence is the one required to convert the argument expression to the referenced type according to [over.best.ics].

Conceptually, this conversion sequence corresponds to copy-initializing a temporary of the referenced type with the argument expression.

Any difference in top-level cv-qualification is subsumed by the initialization itself and does not constitute a conversion.

Except for an implicit object parameter, for which see [over.match.funcs], an implicit conversion sequence cannot be formed if it requires binding an lvalue reference other than a reference to a non-volatile const type to an rvalue or binding an rvalue reference to an lvalue of object type.

[Note 1:

This means, for example, that a candidate function cannot be a viable function if it has a non-const lvalue reference parameter (other than the implicit object parameter) and the corresponding argument would require a temporary to be created to initialize the lvalue reference (see [dcl.init.ref]).

— end note]

Other restrictions on binding a reference to a particular argument that are not based on the types of the reference and the argument do not affect the formation of an implicit conversion sequence, however.

[Example 2:

A function with an “lvalue reference to int” parameter can be a viable candidate even if the corresponding argument is an int bit-field.

The formation of implicit conversion sequences treats the int bit-field as an int lvalue and finds an exact match with the parameter.

If the function is selected by overload resolution, the call will nonetheless be ill-formed because of the prohibition on binding a non-const lvalue reference to a bit-field ([dcl.init.ref]).

— end example]