A typical optimizing compiler can be considered as three parts: a front end, a fuzzily defined (and possibly absent) middle, and a back end.

Front end

The front end of a compiler knows about the syntax and semantics of the language you're compiling, and handles translating that into the internal representation the middle uses.

It takes your code, parses it (generating errors here if your code is syntactically invalid), does semantic analysis of the parsed code (generating errors here if your code doesn't type check, or otherwise has language-specific errors in it), and outputs an internal representation that has the same semantic content as the source code, or an error if it's impossible to do that.

In LLVM land, something like rustc or clang can be driven as a pure front-end, if you tell it to only output LLVM bitcode (which is a serialization form of LLVM's internal representation).

Middle

This is the bit that's target-independent. It takes the internal representation from the front end, analyzes it to find interesting facts for optimizations to work with, optimizes it (in passes, one after the other), and outputs internal representation for the back end to work with.

In some compilers (notably any LLVM based compilers), the optimizations in the middle are very focused, and you use heuristics to determine which optimizations might be worth running at this point in the process.

Some optimizations are also worth rerunning; as an example, dead code elimination can be worth running once on the input from the front end (to remove all the code that's obviously dead, but that was generated from generics, templates, macros or similar mechanisms - with things like obvious tautologies like "is this unsigned value negative?"), and again after something like "value range analysis", where the compiler can now infer that more code is dead because it knows the possible values for some variables, and thus can see that a conditional is always true (for example, if you know that a variable can be between 1 and 2³⁰, you now know that checks to see if it's zero are false).

In simpler compilers, there may be no clear middle; it's not worth separating this from the back end if you're only supporting one language and one target system, and you can mingle this with the back end.

LLVM's opt command is a standalone middle.

Back end

This is the bit that depends on the final target. It takes internal representation from the middle, applies any target specific optimizations (those which are only applicable for this target, such as converting arithmetic to the form needed for x86's LEA instruction where possible), does register allocation (choosing which registers to use for which bits of data) and spilling (moving data to and from memory to allow for not having enough registers), converts to instructions, and does instruction scheduling.

These bits all end up intertwined; on an out-of-order CPU, for example, instruction scheduling wants to push instructions as far away as possible from the instructions that generate their input values (so that the previous instructions are more likely to have completed by the time the CPU considers this instruction), while register allocation wants to keep instructions close together so that registers are live for the smallest time (and thus reusable for other data).

Most CPUs have more than one sequence that can implement the same outcome, and the "right" one to use varies by CPU and code details; for example, do you use a conditional instruction (like CSEL or CMOV), or a branch? Additionally, some (mostly older or special purpose) ISAs have delay slots or other oddities that have to be considered during instruction scheduling; you may not be able to read the destination of a multiply instruction until a set number of instructions after the multiply itself, or might have delay slots after branches (instructions that come after a branch in program order, but which are unconditionally executed before the branch - these are especially nasty when they apply to conditional branches).

LLVM's llc is a standalone backend.

I think you have got some good answers from persons actually involved in modern compilers. I will take a slightly different approach - about econonomics. Lets start with some assumptions:

There are a lot of different programming languages. From the top of my head i can recall 8 different ones: Ada, C, C++, Fortran, Cobol, Pascal, Algol, Rust. Wikipedia has long list of languages, but I have selectively pointed out a few.

There are lot of different computer architectures. From the top of my head I can recall 4 different ones: x86, arm, ibm z, risc-v. Again, there are a lot more.

So if you want to support all languages on all architecture you need to have 32 different compilers (8 x 4). But if you draw a line somewhere between the language and the architecture you only need to create 12 compilers (8 + 4). We may call the parts on one side of the line front-end, and the parts on the other side back-end, why not? Could be a lot less expensive.

As it happens, this is what is done by as example LLVM. It has several front-ends, one per language, and several backends, one per architecture. Exactly where that line is drawn, if there are additional middle layers, and how tha different parts communicate are design decisions specific for LLVM. Other compilers have in history and over time made different decisions.

So to come back to your question. Frontend and backend are general concepts, but exact implementaiton is dependant on which compiler you use. Optimizations, as example, can be done in several steps, maybe parts in the front-end and some parts in the middle and some in the back-end -- all dependant on the exact compiler.

The term “intermediate representation” implies that it’s between front end and back end, and many compiler textbooks describe the “front” as converting from source to some kind of abstract syntax tree, the “middle” as transforming that intermediate representation into another, and the “back” as transforming that into the target language. “Crafting interpreters,” for one, uses climbing up one side of a mountain and down the other as a recurring metaphor for compilation.

You start off at the bottom with the program as raw source text, literally just a string of characters. Each phase analyzes the program and transforms it to some higher-level representation where the semantics—what the author wants the computer to do—become more apparent.

Eventually we reach the peak. We have a bird’s-eye view of the user’s program and can see what their code means. We begin our descent down the other side of the mountain. We transform this highest-level representation down to successively lower-level forms to get closer and closer to something we know how to make the CPU actually execute.